搭建主从复制案例

停止使用 GTID：
MySQL [(none)]> change master to master_auto_position=0;
主库查看有多少个从库：
MySQL [(none)]> show slave hosts;
主从复制架构图：
主库有个 binlog cache：定期收集主库变化的信息，当提交时，将 binlog cache 中的
binlog 写入磁盘的 binlog file 中。
1 步、从库的 io thread 进程:首先主动通过 IP、端口、用户和密码请求和接收主库 dump
thread 进程发送的 binlog 信息，存放到 relay log file 中。
2 步、主库的有个 dump thread 进程：接收从库发出的请求，将主库的 binlog 发送给从
库 3
步、从库的 sql thread 进程：从 relay log file 中将主库的 binlog 应用到数据库中。
4 步、从库的 binlog file：记录从库的变化信息。
主从搭建时确保以下两点不同：
1、 server_id 不能相同；在 mysql 参数文件中修改。
2、 auto.cnf 文件中的 uuid 不能相同，可删除 auto.cnf 文件重启服务器自动生成一个新
的 auto.cnf 文件。
binlog 格式有三种：
statement:记录导致数据变化的 sql 语句；row：记录数据变化。例如记录 id 从 1 变成 2 的记录(在主从复制的场景下可避免主从数
据不一致的情况)，对网络要求较高。
搭建主从复制
1、修改主库参数：
binlog-do-db = #仅记录指定数据库的 binlog —不建议使用
binlog-ignore-db = # 需要被忽略的库 —不建议使用
max_binlog_size = 2048M # 默认为 1024M —1024M 一个 binlog 文件大小进行截
断
binlog_format = ROW # 必须为 ROW
transaction-isolation = READ-COMMITTED
expire_logs_days = 7 # binlog 保留多少天，看公司计划安排
server-id = 111 # 必须和所有从机不一样，且从机之间也不一样
binlog_cache_size = # binlog 缓存的大小，设置时要当心
sync_binlog = 1 # 必须设置为 1，默认为 0， commit 就落盘
innodb_flush_log_at_trx_commit = 1 # 提交事物的时候刷新日志， commit 就落盘
2、主库创建对应的用户并授权：
mysql> create user ‘rep’ @ ‘%’ identified by ‘Of123456’;
mysql> grant replication slave on . to ‘rep’@’%’;
mysql> flush privileges;
3、修改从库参数：log_slave_updates # 将 SQL thread 线程的数据写入到从机的 binlog 中去(用于级联复
制),用于主从从的场景需要开启。
replicate-do-db = # 需要复制的库 —不建议使用
replicate-ignore-db = # 需要忽略的库 —不建议使用
replicate-do-table = # 需要复制的表 —不建议使用
replicate-ignore-table = 需要忽略的表 —不建议使用
server-id = 112 # 必须在一个复制集群环境中全局唯一
relay-log-recover = 1 # I/O thread crash safe – IO 线程安全
relay_log_info_repository = TABLE # SQL thread crash safe – SQL 线程安全
4、如果是在线搭建主从需要在备份对主库进行备份恢复。
mysqldump -uroot -pOf123456 --master-data=2 --single-transaction -A > all.sql
备库应用
mysql>source /mnt/all.sql
5、从库配置主从复制：
(如果从库无法配置主从，需要清空从库的 binlog(reset master;)和重置主从复制(reset
slave all;)
主库查询： mysql> show master status;
备库执行：
mysql> change master to
master_host=‘192.168.1.11’,master_user=‘rep’,master_password=‘Of123456’,maste
r_log_file=‘binlog.000019’,master_log_pos=190,master_port=3306;使用基于 GTID 的复制时（MASTER_AUTO_POSITION = 1）：
mysql> change master to
master_host=‘192.168.1.11’,master_user=‘rep’,master_password=‘Of123456’,maste
r_port=3306,MASTER_AUTO_POSITION = 1;
–master_host=#指定主库实例 IP
–master_user=#指定主库用户名
–master_password=#指定主库用户密码
–master_port=#指定主库实例端口号
–master_log_file=#指定主库上的 binlog file
–master_log_pos=#指定主库上的 pos
6、从库启动同步，开始同步数据：
start slave;
远程连接 mysql 测试：
mysql -h 192.168.5.116 -P3306 -urep -p123456
备库查看主备同步状态(主库是无法使用该命令查看)：
show slave status\G;
主备库同步正常的标志：
Slave_IO_Running:Yes
Slave_SQL_Running:Yes
7、配置半同步复制需要先配置异步复制(mysql 下执行)加载插件（主库和从库都需要安装插件）
主库
INSTALL PLUGIN rpl_semi_sync_master SONAME ‘semisync_master.so’;
从库
INSTALL PLUGIN rpl_semi_sync_slave SONAME ‘semisync_slave.so’;
8、启动半同步复制（在安装完插件后，半同步复制默认是关闭的，这时需设置参数来开
启半同步）
主库
SET GLOBAL rpl_semi_sync_master_enabled = 1;
从库
SET GLOBAL rpl_semi_sync_slave_enabled = 1;
9、从库重启 IO 线程
STOP SLAVE IO_THREAD;
START SLAVE IO_THREAD;
10、主库查询是否开启半同步复制：
mysql> show status like ‘%semi%’;
Rpl_semi_sync_master_status：指示主服务器使用的是异步复制模式，还是半同步复制
模式。
Rpl_semi_sync_master_clients：显示有多少个从服务器配置成了半同步复制模式。
Rpl_semi_sync_master_yes_tx：显示从服务器确认的成功提交数量。
Rpl_semi_sync_master_no_tx：显示从服务器确认的不成功提交数量。
11、主库查看有哪些从库：MySQL [(none)]> show slave hosts;
-----------------end------------------------------
io thread 异常的情况：
1、 ip、 port、 user、 passwd 指定有误； ---->连接异常
2、 binlog file pos 指定有误； ---->binlog 获取有误
3、 relay log file 异常。 ----->relay log 权限异常
SQL thread 异常的情况：
1、主键冲突；
2、缺少数据； —>更新数据时缺少更新前的数据库
3、数据类型不一致。
查看主从延迟情况:
Read_Master_Log_Pos: 1173
Exec_Master_Log_Pos: 1173---->可以配合 Read_Master_Log_Pos 查看主从延迟情况
在线搭建主从：
1、将之前的数据库实例进行一致性备份； ---->其中有 binlog file 和 pos
2、根据主库的备份集在从库进行数据恢复；
3、从库 change master ---->应用主库备份集中的 binlog file 和 pos