一、为什么要用mysql集群?:
mysql单体架构在企业中很少用,原因:①会形成单点故障,没有高可用的效果;②mysql本身是一个I/O能力比较差,并发能力比较差的应用服务,在较高规模的网络I/O情况下,单台数据库是无法承受企业级实战应用的;因此我们需要对数据库做集群:集中式集群、分布式集群
集中式架构:以多个客户,通过网络文件共享协议,通过远程过程调用的方式,找到NFS的挂载点,去共享资源。特点是数据的内容是一致性的,缺点是存储压力比较大。如:NFS、NAS、
分布式架构:每台服务器只存自己的一部分(元数据节点和数据节点是怎么关联,如ceph、gfs、mfs),关系型数据库不适合做分布式,因为其最致命弱点是范式要求过于严密;非关系型数据库适用于分布式架构,如:redis、elk、多实例、虚拟化、容器、半联动
微博、微信、公众号数据是半结构化数据,适合存储在非关系数据库中
半联动:优势可以实现异步处理,降低局域网中的主从复制的I/O压力、带宽压力。
二、mysql的主从复制
数据的读取和写入是以业务的方式进行的
1.MySQL复制
扩展方式: 横向扩展 ,纵向扩展
MySQL的扩展
读写分离
复制:每个节点都有相同的数据集
向外扩展
二进制日志
单向(主可以同步从、从不可以同步主,不要在从上面做相关写入的操作)
复制的功用:
数据分布
负载均衡读
备份
高可用和故障切换(高可用:MHA、PXC)
MySQL升级测试
一主一从
app server写入数据到master,master在进行数据同步到从服务器,然后app server 再去读就是读的从服务器。
一主多从
app server 写入master,master同步到多个slave,然后app server读的时候,可以负载均衡读三台服务器
主从复制基本原理
①主节点负责数据的写操作,此时要求主节点启用二进制日志(bin-log),此时数据库的更改写入到二进制日志中。(二进制日志功能:记录sql语句的增删改数据,就会涉及到数据更新,数据更新会写入到bin-log中)
②在MySQL主服务器上会生成开启dump Thread 将新生成的二进制日志读出来,同时通过网络发送给从节点。
③从节点开启I/O线程(I/O Thread,对接主服务器的dump线程,用于接收dump Thread传送过来的二进制日志),使用relay-log存放二进制日志。然后从服务器开启一个单独的线程(SQL Thread,用于读取relay-log 然后执行修改数据库中的数据,便实现了数据更新)
【注】:从服务器可以不用开启二进制日志,但必须开启中继日志(relay-log)
2.主从复制线程:
主节点:
dump Thread:为每个Slave的I/O Thread启动一个dump线程,用于向其发送binary log events
从节点:
I/O Thread:向Master请求二进制日志事件,并保存于中继日志中
SQL Thread:从中继日志中读取日志事件,在本地完成重放
跟复制功能相关的文件:
master.info:用于保存slave连接至master时的相关信息,例如账号、密码、服务器地址等
relay-log.info:保存在当前slave节点上已经复制的当前二进制日志和本地replay log日志的对应关系
3.主从复制特点:
异步复制:主从数据不一致比较常见
复制架构:
Master/Slave, Master/Master, 环状复制
一主多从:从服务器还可以再有从服务器
一从多主:适用于多个不同数据库
复制需要考虑二进制日志事件记录格式:
STATEMENT(5.0之前)、ROW(5.1之后,推荐)、MIXED
4.主从配置过程:
MySQL Replication Master | MariaDB Knowledge Base
MySQL :: MySQL 8.0 Reference Manual :: 19.1 Configuring Replication
主节点配置:
(1) 启用二进制日志
[mysqld]
log_bin
(2) 为当前节点设置一个全局惟一的ID号
[mysqld]
server_id=#
log-basename=master 可选项,设置datadir中日志名称,确保不依赖主机名
(3)创建有复制权限的用户账号
create user 'repluser'@'%';
alter user 'repluser'@'%' identified with mysql_native_password by '123456';
GRANT REPLICATION SLAVE ON *.* TO 'repluser'@'HOST';
(4) 在从节点使用有复制权限的用户账号连接至主服务器,并启动复制线程
mysql> change master to
-> master_host='192.168.10.100',
-> master_user='repluser',
-> master_password='123456',
-> master_port=3306,
-> master_log_file='mysql-bin.000001',
-> master_log_pos=157;
高版本:
mysql> CHANGE REPLICATION SOURCE TO
-> SOURCE_HOST='192.168.10.100',
-> SOURCE_USER='repluser',
-> SOURCE_PASSWORD='123456',
-> SOURCE_PORT=3306,
-> SOURCE_LOG_FILE='mysql-bin.000001',
-> SOURCE_LOG_POS=157;
未开启MySQL从节点线程之前,使用show slave status\G / SHOW REPLICA STATUS\G(高版本) 查看从节点的线程是否开启和状态信息
主节点和从节点查看线程信息:show processlist;
开启从节点主从同步线程 start slaves; / START REPLICA;(高版本)
5.主从配置故障诊断:
如果主节点已经运行了一段时间,且有大量数据时,如何配置并启动slave节点
①通过备份恢复数据至从服务器
②复制起始位置为备份时,二进制日志文件及其POS
步骤总结:
①:修改master主节点配置 server-id log-bin
②:重启服务
③:备份master数据库,并添加--master-data=1
④:将备份的SQL脚本scp到新的从节点
⑤:从节点配置主配置文件的server-id read-only等
⑥:编辑拷贝的SQL脚本,加入change master to
⑦:进入SQL接口临时关闭二进制日志,导入主节点所有数据,开启slave线程,再开启二进制日志。
如果要启用级联复制,需要在从服务器启用以下配置
[mysqld]
log_bin
log_slave_updates
6.复制架构中应该注意的问题
1、限制从服务器为只读
在从服务器上设置read_only=ON
注意:此限制对拥有SUPER权限的用户均无效
阻止所有用户, 包括主服务器复制的更新
mysql> FLUSH TABLES WITH READ LOCK;
2、RESET SLAVE --->清除中继日志
在从服务器清除master.info ,relay-log.info, relay log ,开始新的relay log ,注意:需要先STOP SLAVE
RESET SLAVE ALL 清除所有从服务器上设置的主服务器同步信息如:PORT, HOST, USER和 PASSWORD 等
3、sql_slave_skip_counter = N / sql_replica_skip_counter = N 从服务器忽略几个主服务器的复制事件, 或者使用slave_skip_levels = ALL/CODE,global变量
4、如何保证主从复制的事务安全
Server System Variables - MariaDB Knowledge Base
在master节点启用参数:
sync_binlog=1 每次写后立即同步二进制日志到磁盘,性能差
如果用到的为InnoDB存储引擎:
innodb_flush_log_at_trx_commit=1 每次事务提交立即同步日志写磁盘
innodb_support_xa=ON 默认值,分布式事务MariaDB10.3.0废除
sync_master_info=# #次事件后master.info同步到磁盘
在slave节点启用服务器选项:
skip_slave_start=ON 不自动启动slave
在slave节点启用参数:
sync_relay_log=# #次写后同步relay log到磁盘
sync_relay_log_info=# #次事务后同步relay-log.info到磁盘
三、MySQL读写分离
读写分离应用:
mysql-proxy:Oracle,https://downloads.mysql.com/archives/proxy/
Atlas:Qihoo,https://github.com/Qihoo360/Atlas/blob/master/README_ZH.md
dbproxy:美团,https://github.com/Meituan-Dianping/DBProxy
Cetus:网易乐得,https://github.com/Lede-Inc/cetus
Amoeba:https://sourceforge.net/projects/amoeba/
Cobar:阿里巴巴,Amoeba的升级版
Mycat:基于Cobar, http://www.mycat.io/
ProxySQL:https://proxysql.com/
mycat介绍:
在整个IT系统架构中,数据库是非常重要的,通常又是访问压力比较大的一个服务,除了在程序开发的本身上做优化,代码优化,数据库的处理本身优化也是非常重要的。主从、热备、分表分库等都是系统发展迟早遇到的技术。
mycat是一个广受好评的数据库中间件,已经在很多产品上进行使用。
mycat是一个开源的分布式数据库系统,实现MYSQL协议,前端用户可以把它看作一个数据库代理。
核心功能是分库分表,将一个大表水平分隔为N个小表,存储在后端MySQL服务器里或者其他数据库里。
MyCat 是一个彻底开源的,面向企业应用数据库中间件 , 支持事务, 可以视为MySQL集群的企业级数据库,用来替代昂贵的Oracle集群, 在MyCat 中融合内存缓存技术、NoSQL技术、HDFS大数据的新型SQL Server ,并结合传统数据库和新型分布式数据仓库的新一代企业级数据库中间件产品
操作步骤:
①:mycat依赖java环境,需要安装jdk
yum -y install java mariadb
②:tar xf Mycat-server.tar.gz -C /usr/local/
③:cd /usr/local/mycat/
④:PATH=$PATH:/usr/local/mycat/bin/ 临时生效
⑤:mycat start 先让mycat生效,预运行一下
⑥:ls /usr/local/mycat/logs/wrapper.log 运行日志查看
在客户机上尝试连接代理服务器 mysql -u root -h 192.168.10.130 -p -P 8066
⑦:更改mycat主配置文件和后台代理配置文件
vim /usr/local/mycat/conf/server.xml
vim /usr/local/mycat/conf/schema.xml
⑧:mycat restart 重启mycat服务
⑨:验证读写分离性效果(在mycat代理节点查询server_id验证读操作,在主节点开启通用日志,查看写操作)
【注】:mycat不仅可以实现读写分离,还可以实现主从健康状态监测,若读节点健康出问题,会将读操作转移到写节点运行。mycat无法解决主节点宕机的故障迁移,可以基于keepalived实现mycat的高可用集群。