MYSQL主从同步的作用
一、半同步复制原理介绍
1. 优点
当事务返回客户端成功后，则日志一定在至少两台主机上存在。
MySQL在加载并开启Semi-sync插件后，每一个事务需等待备库接收日志后才返回给客户端。如果做的是小事务，两台主机的延迟又较小，则Semi-sync可以实现在性能很小损失的情况下的零数据丢失。
2. 缺点
完成单条事务增加了额外的等待延迟，延迟的大小取决于网络的好坏。
Semi-sync不是分布式事务，主库会在自己完成事务后，等待备库接收事务日志。
3. 主机Crash时的处理
备库Crash时，主库会在某次等待超时后，关闭Semi-sync的特性，降级为普通的异步复制，这种情况比较简单。
主库Crash后，那么可能存在一些事务已经在主库Commit，但是还没有传给任何备库，我们姑且称这类事务为"墙头事务"。"墙头事务"都是没有返回给客户端的，所以发起事务的客户端并不知道这个事务是否已经完成。
这时，如果客户端不做切换，只是等Crash的主库恢复后，继续在主库进行操作，客户端会发现前面的"墙头事务"都已经完成，可以继续进行后续的业务处理；另一种情况，如果客户端Failover到备库上，客户端会发现前面的“墙头事务”都没有成功，则需要重新做这些事务，然后继续进行后续的业务处理。
4. 其他
可以做多个备库，任何一个备库接收完成日志后，主库就可以返回给客户端了。
网络传输在并发线程较多时，一次可能传输很多日志，事务的平均延迟会降低。
"墙头事务"在墙头上的时候，是可以被读取的，但是这些事务在上面Failover的场景下，是被认为没有完成的。
5. 半同步复制插件安装
1. 安装
-------------------------------------
在master上安装master插件:
mysql> INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so';
在slave上安装slave插件;
mysql> INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so';
2. 必须同时两端激活
-------------------------------------
在运行时:
在master上执行:
mysql> SET GLOBAL rpl_semi_sync_master_enabled = 1; mysql> SET GLOBAL rpl_semi_sync_master_timeout = 3000;
在slave上执行:
mysql> SET GLOBAL rpl_semi_sync_slave_enabled = 1; mysql> STOP SLAVE IO_THREAD; START SLAVE IO_THREAD;
3. 监视
-------------------------------------
看配置
SHOW VARIABLES LIKE 'rpl_semi_sync%';
看状态:
SHOW STATUS LIKE 'rpl_semi_sync%';
二、主从复制原理介绍
一、MySQL复制概述
MySQL支持单向、异步复制，复制过程中一个服务器充当主服务器，而一个或多个其它服务器充当从服务器。MySQL复制基于主服务器在二进制日志中跟踪所有对数据库的更改(更新、删除等等)。因此，要进行复制，必须在主服务器上启用二进制日志。每个从服务器从主服务器接收主服务器上已经记录到其二进制日志的保存的更新。当一个从服务器连接主服务器时，它通知主服务器定位到从服务器在日志中读取的最后一次成功更新的位置。从服务器接收从那时起发生的任何更新，并在本机上执行相同的更新。然后封锁并等待主服务器通知新的更新。从服务器执行备份不会干扰主服务器，在备份过程中主服务器可以继续处理更新。
二、复制实现细节
MySQL使用3个线程来执行复制功能，其中两个线程(Sql线程和IO线程)在从服务器，另外一个线程(IO线程)在主服务器。当发出START SLAVE时，从服务器创建一个I/O线程，以连接主服务器并让它发送记录在其二进制日志中的语句。主服务器创建一个线程将二进制日志中的内容发送到从服务器。该线程可以即为主服务器上SHOW PROCESSLIST的输出中的Binlog Dump线程。从服务器I/O线程读取主服务器Binlog Dump线程发送的内容并将该数据拷贝到从服务器数据目录中的本地文件中，即中继日志。第3个线程是SQL线程，由从服务器创建，用于读取中继日志并执行日志中包含的更新。在从服务器上，读取和执行更新语句被分成两个独立的任务。当从服务器启动时，其I/O线程可以很快地从主服务器索取所有二进制日志内容，即使SQL线程执行更新的远远滞后。
1、复制线程状态
通过show slave status\G和show master status可以查看复制线程状态。常见的线程状态有：
(1)主服务器Binlog Dump线程
Has sent all binlog to slave; waiting for binlog to be updated
线程已经从二进制日志读取所有主要的更新并已经发送到了从服务器。线程现在正空闲，等待由主服务器上新的更新导致的出现在二进制日志中的新事件。
(2)从服务器I/O线程状态
Waiting for master to send event
线程已经连接上主服务器，正等待二进制日志事件到达。如果主服务器正空闲，会持续较长的时间。如果等待持续slave_read_timeout秒，则发生超时。此时，线程认为连接被中断并企图重新连接。
(3)从服务器SQL线程状态
Reading event from the relay log
线程已经从中继日志读取一个事件，可以对事件进行处理了。
Has read all relay log; waiting for the slave I/O thread to update it
线程已经处理了中继日志文件中的所有事件，现在正等待I/O线程将新事件写入中继日志。
2、复制过程中使用的传递和状态文件
默认情况，中继日志使用host_name-relay-bin.nnnnnn形式的文件名，其中host_name是从服务器主机名，nnnnnn是序列号。中继日志与二进制日志的格式相同，并且可以用mysqlbinlog读取。
从服务器在data目录中另外创建两个小文件。这些状态文件默认名为主master.info和relay-log.info。状态文件保存在硬盘上，从服务器关闭时不会丢失。下次从服务器启动时，读取这些文件以确定它已经从主服务器读取了多少二进制日志，以及处理自己的中继日志的程度。
如果要备份从服务器的数据，还应备份这两个小文件以及中继日志文件。它们用来在恢复从服务器的数据后继续进行复制。如果丢失了中继日志但仍然有relay-log.info文件，可以通过检查该文件来确定SQL线程已经执行的主服务器中二进制日志的程度。然后可以用Master_Log_File和Master_LOG_POS选项执行CHANGE MASTER TO来告诉从服务器重新从该点读取二进制日志。
三、主从复制的配置方法
1. 在master创建复制用户
grant replication slave on *.* to 'replication'@'192.168.1.%' identified by '000000'; flush privileges;
2. 修改master的配置文件，开启binlog日志和设置需要复制的数据库
[mysqld] server-id = 1 log-bin=/opt/mysql/binlog/mysql-bin binlog_do_db=db1 binlog_ignore_db=mysql binlog_format=mixed
3. 修改slave 配置，指定需要复制的数据库和relaylog的路径
[mysqld] server-id = 2 replicate-do-db=db1 replicate-ignore-db = mysql,information_schema relay-log=/opt/mysql/data/mysqlb-relay-bin relay-log-index=/opt/mysql/data/mysqlb-relay-bin.index
4. 重启master和slave数据库服务器
5. 在master上执行
mysql>flush tables with read lock;
mysql>show master status\G
*************************** 1. row ***************************
File: binlog.000006
Position: 107
Binlog_Do_DB: test
Binlog_Ignore_DB: mysql
1 row in set (0.00 sec)
mysql>unlock tables;
注：这里锁表的目的是为了生产环境中不让进新的数据，好让从服务器定位同步位置。初次同步完成后，记得解锁。
6. 在slave上，使用change master指向同步位置
mysql>change master to master_host='192.168.1.106',master_port=3307, master_user='replication', master_password='000000', master_log_file='binlog.000006', master_log_pos=107;
注：master_log_file，master_log_pos由上面主服务器查出的状态值中确定。master_log_file对应File，master_log_pos对应Position。mysql 5.x以上版本已经不支持在配置文件中指定主服务器相关选项。
7. 启动从服务器复制线程
mysql>start slave; 原文链接 http://haiker.iteye.com/blog/1632697
(1) 数据分布
(2) 负载平衡(load balancing)
(3) 备份
(4) 高可用性(high availability)和容错
MYSQL主从同步的原理
关于MYSQL的主从同步，最主要的是要了解MYSQL的主从同步是如何工作的也即主从同步的原理，通过下图能很明白的指导其工作的过程：
大致描述一下过程：从服务器的IO线程从主服务器获取二进制日志，并在本地保存为中继日志，然后通过SQL线程来在从上执行中继日志中的内容，从而使从库和主库保持一致。主从同步的详细过程如下：
1. 主服务器验证连接。
2. 主服务器为从服务器开启一个线程。
3. 从服务器将主服务器日志的偏移位告诉主服务器。
4. 主服务器检查该值是否小于当前二进制日志偏移位。
5. 如果小于，则通知从服务器来取数据。
6. 从服务器持续从主服务器取数据，直至取完，这时，从服务器线程进入睡眠，主服务器线程同时进入睡眠。
7. 当主服务器有更新时，主服务器线程被激活，并将二进制日志推送给从服务器，并通知从服务器线程进入工作状态。
8. 从服务器SQL线程执行二进制日志，随后进入睡眠状态。
MYSQL主从同步的搭建实战
主从同步的搭建是一项比较细的技术活，前期做好了一些事情会让你在以后的工作中减少很多工作，搭建的时候需要注意一些问题，一会搭建的时候会一边搭建一边介绍需要注意的问题，让初学者能在刚开始的时候就有效的规避掉一些潜在的问题(MYSQL安装这里不做介绍)：
-
1. 主从同步环境介绍
操作系统环境：Centos 5.5 64 bit
MYSQL版本：MYSQL 5.1.50
主服务器的IP：10.1.1.75
从服务器的IP：10.1.1.76
-
2. 在主服务器上建立同步帐号
GRANT REPLICATION SLAVE,FILE ON *.* TO 'replication'@'10.1.1.%' IDENTIFIED BY '123456';
FLUSH PRIVILEGES;
注意：大家在设置权限的时候不要将密码设置过于简单！
-
3. 从服务器配置文件的更改
server-id = 2
replicate-wild-ignore-table=mysql.%
log-slave-updates #这个有需要可以开启
注意：
-
server-id这一项需要认真检查，一定不能和主服务器冲突了，不然到时候会出现莫民其妙的问题，因为同步的时候会会根据server-id做判断，如果server-id一样就不进行同步了，不然可能会导致死循环(主主同步或者环状同步的时候)。
-
有的人会感觉奇怪我这里为什么要使用replicate-wild-ignore-table参数，而不是用replicate-do-db或者replicate-ignore-db来过滤需要同步的数据库和不需要同步的数据库。这里有几个原因：
-
replicate-wild-ignore-table参数能同步所有跨数据库的更新，比如replicate-do-db或者replicate-ignore-db不会同步类似
use mysql;
UPDATE test.aaa SET amount=amount+10;
-
B. replicate-wild-ignore-table=mysql.%在以后需要添加同步数据库的时候能方便添加而不需要重新启动从服务器的数据库。因为以后很可能需要同步其他的数据库。
-
3) auto_increment_increment和auto_increment_offset参数，这 两个参数一般用在主主同步中，用来错开自增值, 防止键值冲突。
-
4) --slave-skip-errors参数，不要胡乱使用这些跳过错误的参数，除非你非常确定你在做什么。当你使用这些参数时候，MYSQL会忽略那些错误，这样会导致你的主从服务器数据不一致。
-
4. 从主服务器得到一个快照版本
如果你的是MYISAM或者既有MYISAM又有INNODB的话就在主服务器上使用如下命令导出服务器的一个快照：
mysqldump -uroot -p --lock-tables --events --triggers --routines --flush-logs --master-data=2 --databases test > db.sql
试过只有INNODB的话就是用如下命令：
mysqldump -uroot -p --single-transaction --events --triggers --routines --flush-logs --master-data=2 --databases test > db.sql
这里需要注意几个参数的使用：
--single-transaction 这个参数只对innodb适用。
--databases 后面跟除mysql以后的其他所有数据库的库名，我这里只有一个test库。
--master-data 参数会记录导出快照时候的mysql二进制日志位置，一会会用到。
-
5. 将快照版本还原到从服务器上
mysqldump -uroot -p -h 10.1.1.76 test < db.sql
将快照版本还原到从服务器上以后，此时从服务器上的数据和主服务器的数据是一致的。
-
6. 在从服务器上使用change master从主服务器上同步
使用grep命令查找到二进制日志的名称以及位置
[root@ns1 ~]# grep -i "change master" db.sql
-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000006', MASTER_LOG_POS=106;
生成CHANGE MASTER语句，然后在从上执行
STOP SLAVE;
CHANGE MASTER TO MASTER_HOST='10.1.1.75',MASTER_USER='replication',MASTER_PASSWORD='123456',MASTER_LOG_FILE='mysql-bin.000006', MASTER_LOG_POS=106;
START SLAVE;
这样就完成了主从同步的搭建，最后使用SHOW SLAVE STATUS\G;查看Slave_IO_Running和Slave_SQL_Running的状态，如果都为Yes，就大功告成了。
注意:不要将同步的信息写入配置文件中，不方便管理，尤其是有变动需要重启。
MYSQL主从同步的管理
这里介绍一些管理MYSQL主从同步的命令：
-
1. 停止MYSQL同步
STOP SLAVE IO_THREAD; #停止IO进程
STOP SLAVE SQL_THREAD; #停止SQL进程
STOP SLAVE; #停止IO和SQL进程
-
2. 启动MYSQL同步
START SLAVE IO_THREAD; #启动IO进程
START SLAVE SQL_THREAD; #启动SQL进程
START SLAVE; #启动IO和SQL进程
-
3. 重置MYSQL同步
RESET SLAVE;
用于让从属服务器忘记其在主服务器的二进制日志中的复制位置, 它会删除master.info和relay-log.info文件，以及所有的中继日志，并启动一个新的中继日志,当你不需要主从的时候可以在从上执行这个操作。不然以后还会同步，可能会覆盖掉你的数据库，我以前就遇到过这样傻叉的事情。哈哈！
-
4. 查看MYSQL同步状态
SHOW SLAVE STATUS;
这个命令主要查看Slave_IO_Running、Slave_SQL_Running、Seconds_Behind_Master、Last_IO_Error、Last_SQL_Error这些值来把握复制的状态。
-
5. 临时跳过MYSQL同步错误
经常会朋友mysql主从同步遇到错误的时候，比如一个主键冲突等，那么我就需要在确保那一行数据一致的情况下临时的跳过这个错误，那就需要使用SQL_SLAVE_SKIP_COUNTER = n命令了，n是表示跳过后面的n个事件,比如我跳过一个事件的操作如下：
STOP SLAVE;
SET GLOBAL SQL_SLAVE_SKIP_COUNTER=1;
START SLAVE;
-
6. 从指定位置重新同步
有的时候主从同步有问题了以后，需要从log位置的下一个位置进行同步，相当于跳过那个错误，这时候也可以使用CHANGE MASTER命令来处理，只要找到对应的LOG位置就可以,比如：
CHANGE MASTER TO MASTER_HOST='10.1.1.75',MASTER_USER='replication',MASTER_PASSWORD='123456',MASTER_LOG_FILE='mysql-bin.000006', MASTER_LOG_POS=106;
START SLAVE;
MYSQL主从同步的管理经验介绍
-
1. 不要乱使用SQL_SLAVE_SKIP_COUNTER命令。
这个命令跳过之后很可能会导致你的主从数据不一致，一定要先将指定的错误记录下来，然后再去检查数据是否一致，尤其是核心的业务数据。
-
2. 结合percona-toolkit工具pt-table-checksum定期查看数据是否一致。
这个是DBA必须要定期做的事情，呵呵，有合适的工具何乐而不为呢？另外percona-toolkit还提供了对数据库不一致的解决方案，可以采用pt-table-sync，这个工具不会更改主的数据。还可以使用pt-heartbeat来查看从服务器的复制落后情况。具体的请查看： http://blog.chinaunix.net/uid-20639775-id-3229211.html。
-
3. 使用replicate-wild-ignore-table选项而不要使用replicate-do-db或者replicate-ignore-db。
原因已经在上面做了说明。
-
4. 将主服务器的日志模式调整成mixed。
-
5. 每个表都加上主键，主键对数据库的同步会有影响尤其是居于ROW复制模式。
MySQL基于GTID的主从复制
原创
张晨chat2018-09-22 11:09:02博主文章分类：Mysql©著作权
文章标签GTID主从复制mysql5.7张晨文章分类MySQL数据库阅读数9612
1、什么是GTID？
master_auto_position 自动匹配
binlog position
1、全局唯一，一个事务对应一个GTID
2、替代传统的binlog+pos复制；使用master_auto_position=1自动匹配GTID断点进行复制
3、MySQL5.6开始支持
4、在传统的主从复制中，slave端不用开启binlog；但是在GTID主从复制中，必须开启binlog
5、slave端在接受master的binlog时，会校验GTID值
6、为了保证主从数据的一致性，多线程同时执行一个GTID- 1.
- 2.
- 3.
- 4.
- 5.
- 6.
2、组成
Master_UUID:序列号举例：ceb0ca3d-8366-11e8-ad2b-000c298b7c9a:1-5ceb0ca3d-8366-11e8-ad2b-000c298b7c9a其实就是master的uuid值；1-5是序列号，每次一个事务完成都会自增1，也就是说下一次为1-6。- 1.
3、工作原理
1、master更新数据时，会在事务前产生GTID，一同记录到binlog日志中。
2、slave端的i/o 线程将变更的binlog，写入到本地的relay log中。
3、sql线程从relay log中获取GTID，然后对比slave端的binlog是否有记录。
4、如果有记录，说明该GTID的事务已经执行，slave会忽略。
5、如果没有记录，slave就会从relay log中执行该GTID的事务，并记录到binlog。
6、在解析过程中会判断是否有主键，如果没有就用二级索引，如果没有就用全部扫描- 1.
- 2.
- 3.
- 4.
- 5.
- 6.
4、GTID主从配置
版本：MySQL5.7
配置master
vim /etc/my.cnf
[client]
socket=/usr/local/mysql/mysql.sock
[mysqld]
basedir=/usr/local/mysql
datadir=/usr/local/mysql/data
user=mysql
pid-file=/usr/local/mysql/data/mysqld.pid
log-error=/usr/local/mysql/data/mysql.err
socket=/usr/local/mysql/mysql.sock
port=3306
server-id=1
gtid-mode=ON
enforce-gtid-consistency=ON
server-id=1
binlog_format=row
log-bin=/usr/local/mysql/data/mysql-bin
systemctl restart mysqld
firewall-cmd --add-port=3306/tcp --permanent
firewall-cmd --reload- 1.
- 2.
- 3.
- 4.
- 5.
- 6.
- 7.
- 8.
- 9.
- 10.
- 11.
- 12.
- 13.
- 14.
- 15.
- 16.
- 17.
- 18.
- 19.
- 20.
配置slave
vim /etc/my.cnf
[client]
socket=/usr/local/mysql/mysql.sock
[mysqld]
basedir=/usr/local/mysql
datadir=/usr/local/mysql/data
user=mysql
pid-file=/usr/local/mysql/data/mysqld.pid
log-error=/usr/local/mysql/data/mysql.err
socket=/usr/local/mysql/mysql.sock
port=3306
server-id=2
gtid-mode=ON
enforce-gtid-consistency=ON
server-id=2
binlog_format=ROW
log-bin=/usr/local/mysql/data/mysql-bin
log_slave_updates=ON
skip-slave-start=1
systemctl restart mysqld
firewall-cmd --add-port=3306/tcp --permanent
firewall-cmd --reload- 1.
- 2.
- 3.
- 4.
- 5.
- 6.
- 7.
- 8.
- 9.
- 10.
- 11.
- 12.
- 13.
- 14.
- 15.
- 16.
- 17.
- 18.
- 19.
- 20.
- 21.
- 22.
master授权配置
mysql -uroot -p
mysql> grant replication slave on *.* to 'rep'@'10.0.0.%' identified by '123';
mysql> flush privileges;- 1.
- 2.
- 3.
slave配置同步
mysql -uroot -p
mysql> change master to master_host='10.0.0.132', master_user='rep',master_password='123',master_port=3306,master_auto_position=1;
mysql> start slave;- 1.
- 2.
- 3.
查看slave的状态
mysql> show slave status\G;
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 10.0.0.132
Master_User: rep
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000003
Read_Master_Log_Pos: 635
Relay_Log_File: slave-relay-bin.000005
Relay_Log_Pos: 848
Relay_Master_Log_File: mysql-bin.000003
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 635
Relay_Log_Space: 1308
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 1
Master_UUID: ceb0ca3d-8366-11e8-ad2b-000c298b7c9a
Master_Info_File: /usr/local/mysql/data/master.info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
Master_Retry_Count: 86400
Master_Bind:
Last_IO_Error_Timestamp:
Last_SQL_Error_Timestamp:
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set: ceb0ca3d-8366-11e8-ad2b-000c298b7c9a:1-4
Executed_Gtid_Set: ceb0ca3d-8366-11e8-ad2b-000c298b7c9a:1-4
Auto_Position: 1
Replicate_Rewrite_DB:
Channel_Name:
Master_TLS_Version:
1 row in set (0.00 sec)- 1.
- 2.
- 3.
- 4.
- 5.
- 6.
- 7.
- 8.
- 9.
- 10.
- 11.
- 12.
- 13.
- 14.
- 15.
- 16.
- 17.
- 18.
- 19.
- 20.
- 21.
- 22.
- 23.
- 24.
- 25.
- 26.
- 27.
- 28.
- 29.
- 30.
- 31.
- 32.
- 33.
- 34.
- 35.
- 36.
- 37.
- 38.
- 39.
- 40.
- 41.
- 42.
- 43.
- 44.
- 45.
- 46.
- 47.
- 48.
- 49.
- 50.
- 51.
- 52.
- 53.
- 54.
- 55.
- 56.
- 57.
- 58.
- 59.
- 60.
出现这两个yes表示同步成功
通过slave的状态信息，可以看到GTID的值、Matser_UUID等信息
查看master状态
mysql> show master status;
+------------------+----------+--------------+------------------+------------------------------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+------------------------------------------+
| mysql-bin.000003 | 635 | | | ceb0ca3d-8366-11e8-ad2b-000c298b7c9a:1-4 |
+------------------+----------+--------------+------------------+------------------------------------------+
1 row in set (0.00 sec)- 1.
- 2.
- 3.
- 4.
- 5.
- 6.
- 7.
注意对比slave端，Executed_Gtid_Set的值应该是一样的。
5、验证主从
master上
mysql> create database test01;
Query OK, 1 row affected (0.00 sec)
mysql> show master status;
+------------------+----------+--------------+------------------+------------------------------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+------------------------------------------+
| mysql-bin.000003 | 800 | | | ceb0ca3d-8366-11e8-ad2b-000c298b7c9a:1-5 |
+------------------+----------+--------------+------------------+------------------------------------------+
1 row in set (0.00 sec)- 1.
- 2.
- 3.
- 4.
- 5.
- 6.
- 7.
- 8.
- 9.
- 10.
slave上
mysql> show databases;
+--------------------+
| Database |
+--------------------+
| information_schema |
| mysql |
| performance_schema |
| sys |
| test01 |
+--------------------+
5 rows in set (0.07 sec)
mysql> show slave status\G;
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 10.0.0.132
Master_User: rep
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000003
Read_Master_Log_Pos: 800
Relay_Log_File: slave-relay-bin.000005
Relay_Log_Pos: 1013
Relay_Master_Log_File: mysql-bin.000003
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 800
Relay_Log_Space: 1473
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 1
Master_UUID: ceb0ca3d-8366-11e8-ad2b-000c298b7c9a
Master_Info_File: /usr/local/mysql/data/master.info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
Master_Retry_Count: 86400
Master_Bind:
Last_IO_Error_Timestamp:
Last_SQL_Error_Timestamp:
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set: ceb0ca3d-8366-11e8-ad2b-000c298b7c9a:1-5
Executed_Gtid_Set: ceb0ca3d-8366-11e8-ad2b-000c298b7c9a:1-5
Auto_Position: 1
Replicate_Rewrite_DB:
Channel_Name:
Master_TLS_Version:
1 row in set (0.00 sec)- 1.
- 2.
- 3.
- 4.
- 5.
- 6.
- 7.
- 8.
- 9.
- 10.
- 11.
- 12.
- 13.
- 14.
- 15.
- 16.
- 17.
- 18.
- 19.
- 20.
- 21.
- 22.
- 23.
- 24.
- 25.
- 26.
- 27.
- 28.
- 29.
- 30.
- 31.
- 32.
- 33.
- 34.
- 35.
- 36.
- 37.
- 38.
- 39.
- 40.
- 41.
- 42.
- 43.
- 44.
- 45.
- 46.
- 47.
- 48.
- 49.
- 50.
- 51.
- 52.
- 53.
- 54.
- 55.
- 56.
- 57.
- 58.
- 59.
- 60.
- 61.
- 62.
- 63.
- 64.
- 65.
- 66.
- 67.
- 68.
- 69.
- 70.
- 71.
- 72.
需要注意的是，GTID的值在完成一次事务后，变成了ceb0ca3d-8366-11e8-ad2b-000c298b7c9a:1-5（自增1）
6、排障
思路
a、确保master开放3306端口
b、最好关闭selinux
c、master上授权同步，slave上change master命令指定master的信息不要写错
d、UUID问题
如果你出现了上图所示的问题，表示你的master和slave的UUID是一样的，一般这种情况多出现于克隆虚拟机
解决办法：
找到slave上的MySQL数据目录下的auto.cnf文件（这个文件其实是自动生成的mysql服务器的UUID值），将它删除，然后重启MySQL，然后MySQL会重新生成一个UUID。然后停掉slave，重新开启就可以了（我的mysql的数据目录是在/usr/local/mysql/data下，详情查看my.cnf配置文件）
cd /usr/local/mysql/data
rm -f auto.cnf
systemctl restart mysql- 1.
- 2.
- 3.
[root@slave data]# cat auto.cnf
[auto]
server-uuid=020c7f26-be57-11e8-8e2d-000c29b63bad- 1.
- 2.
- 3.
通过cat命令查看该文件，发现UUID已经改变
mysql -uroot -p
mysql> stop slave;
mysql> start slave;- 1.
- 2.
- 3.
e、总结
排障过程中，注意需要停掉slave，做完修改之后在开启，否则你的修改可能是不会生效的。