mysqlReplication - juedaiyuer/researchNote GitHub Wiki
#mysql复制功能#
MySQL复制功能提供分担读负载
为高可用,灾难恢复,备份提供更多的选择
复制解决了什么问题
- 实现在不同服务器上的数据分布
- 利用二进制日志增量进行
- 不需要太多的带宽
- 但是使用基于行的复制在进行大批量更改时会对带宽带来一定的压力
- 特别是跨IDC环境进行复制
- 应该分批进行
- 实现数据读取的负载均衡,需要其它组件配合完成,利用DNS轮询的方式把程序的读连接到不同的备份数据库；使用LVS,haproxy这样的代理方式
- 非共享架构,同样的数据分布在多台服务器上,增强了数据安全性
- 利用备库的备份来减少主库负载,复制并不能代替备份
- 方便进行数据库高可用的部署,避免MySQL单点失败
- 实现数据库高可用和故障切换
- 实现数据库在线升级
##MySQL复制工作方式##
- 主将变更写入二进制日志
- 从读取主的二进制日志变更并写入到relay_log中
- 在从上重放relay_log中的日志
###基于日志点的复制配置步骤###
在主DB服务器上建立复制帐号
#建议复制帐号只对存在从服务器的网段进行授权
CREATE USER 'repl'@'ip段' IDENTIFIED BY 'password';
#授权
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'ip段';
#ip段
192.168.3.%
配置主数据库服务器
bin_log=mysql-bin
server-id=100
配置从数据库服务器
bin_log=mysql-bin
server-id=101
relay_log=mysql-relay-bin
log_slave_update=on 可选
read_only=on 可选
初始化从服务器数据
主服务器的数据拷贝到从服务器
mysqldump --master-data=2 -single-transaction
#实例
mysqldump --single-transaction --master-data --triggers --routines --all-databases >> all.sql
#备份文件传输到从服务器
scp all.sql slavename@ip
#导入备份文件
mysql -uroot -p <all.sql
逻辑备份
使用这个命令会对表进行加锁,影响数据库并发性；在一个访问非常频繁进行备份会造成大量的阻塞
xtarbackup --slave-info
热备份
启动复制链路
#在从服务器上执行
CHANGE MASTER TO MASTER_HOST='master_host_ip',
MASTER_USER='repl',
MASTER_PASSWORD='password',
MASTER_LOG_FILE='mysql_log_file_name',
MASTER_LOG_POS=4;
MASTER_LOG_FILE和MASTER_LOG_POS参数在all.sql文件中可以获得
#复制链路的查看
mysql> show slave status \G;
#启动复制链路
mysql> start slave;
mysql> show processlist;
优点
- MySQL最早支持的复制技术,Bug相对较少
- 对SQL查询没有任何限制
- 故障处理比较容易
缺点
- 故障转移时重新获取新主的日志点信息比较困难
###基于GTID的复制配置步骤###
5.6版本支持
什么是GITD
GTID即全局事务ID,其保证为每一个在主上提交的事务在复制集群中可以生成一个唯一的ID
GTID=source_id:transaction_id
在主DB服务器上建立复制帐号
相同
配置主数据库服务器
bin_log=/usr/local/mysql/log/mysql-bin
server_id=100
gtid_mode=on
enforce-gtid-consiste
log-slave-updates=on 5.7版本不需要该参数
启动强制一致性无法使用的命令
create table ... select
在事务中使用Create temporary table 建立临时表
使用关联更新事务表和非事务表
配置从数据库服务器
server_id=101
relay_log=/usr/local/mysql/log/relay_log
gtid_mode=on
enforce-gtid-consiste
read_only=on [建议]
master_info_repository=TABLE [建议]
relay_log_info_repository=TABLE [建议]
初始化从服务器数据
记录备份时最后的事务的GTID值
启动基于GTID的复制
#在从服务器上执行
CHANGE MASTER TO MASTER_HOST='master_host_ip',
MASTER_USER='repl',
MASTER_PASSWORD='password',
MASTER_AUTO_POSITION=1
#查看用户
mysql> select user,host from user;
#查看授权
mysql> show grants for username@ip;
#重启数据库服务器
/etc/init.d/mysqld restart
mysqldump --single-transaction --master-data=2 --triggers --routines --all-databases >all2.sql
scp -p22 all2.sql 远程主机名@ip:/目录
优点
- 可以很方便的进行故障转移
- 从库不会丢失主库上的任何修改
缺点
- 故障处理比较复杂
- 对执行的SQL有一定的限制
###选择复制模式要考虑的问题###
- 所使用的MySQL版本
- 复制架构及主从切换的方式
- 所使用的高可用管理组件
- 对应用的支持程度
##mysql复制拓扑##
MySQL5.7之前,一个从库只能有一个主库
MySQL5.7之后支持一从多架构
优点
- 配置简单
- 可以用多个从库分担读负载
用途
- 为不同业务使用不同的从库(前后台分离)
- 将一台从库放到远程IDC,用作灾备恢复
- 分担主库的读负载
- 主备模式的主主复制
- 主主模式的主主复制
###主主模式的主主复制的配置注意事项###
-
产生数据冲突而造成复制链路的中断
-
耗费大量的时间,造成数据的丢失
-
使用场景:两个地区,两个数据库
-
两个主中所操作的表最好能够分开
-
除非真的有需求,否则不推荐使用
#使用参数控制自增ID的生成 auto_increment_increment=2 步长 auto_increment_offset = 1 | 2 自增id从哪个数值开始
###主备模式的主主复制的配置注意事项###
- 只有一台主服务器对外提供服务
- 一台服务器处于只读状态并且只作为热备使用
- 在对外提供服务的主库出现故障或是计划性的维护时才会进行切换
- 使原来的备库成为主库,而原来的主库会成为新的备库并处理只读或是下线状态,待维护完成后重新上线
- 可作为高可用的方案来使用
配置注意事项
- 确保两台数据库上的初始数据相同
- 确保两台服务器已经启动binlog并且有不同的server_id
- 在两台服务器上启用log_slave_updates参数
- 在初始的备库上启用read_only
- 分发主库slave_log_updates参数
##MySQL复制性能优化##
###影响主从延迟的因素###
- 主库写入二进制日志的时间---控制主库的事务大小,分割大事务
- 二进制日志传输时间---传输日志量的大小,使用MIXED日志格；设置set binlog_row_image=minimal
- 默认情况下只有一个SQL线程,主上并发的修改在从上变成了串行---使用多线程复制
多线程复制
在MySQL5.7中可以按照逻辑时钟的方式来分配SQL线程
如何配置多线程复制
stop slave 停止链路复制
set global slave_parallel_type='logic_clock';
set global slave_parallel_workers=4; 复制线程的数量
start slave;
##复制常见问题处理##
由于数据损坏或丢失所引起的主从复制错误
非正常关机引起的
- 主库或从库意外宕机引起的错误--使用跳过二进制日志事件,注入空事务的方式先恢复中断的复制链路,再使用其它方法对比主从服务器上的数据
- 主库上的二进制日志损坏--通过change master命令重新来指定
- 备库上的中继日志损坏
- 在从库上进行数据修改造成的主从复制错误---从库read_only参数
- 不唯一的server_id或server_uuid
- max_allow_packet设置引起的主从复制错误
server_uuid是记录在数据目录中的auto.cnf文件中
MySQL复制无法解决的问题
- 分担主数据库的写负载---分库分表
- 自动进行故障转移及主从切换
- 提供读写分离功能