MySQL 复制的基本过程
![mysql主备同步](http://www.kryptosx.info/wp-content/uploads/2015/08/mysql%E4%B8%BB%E5%A4%87%E5%90%8C%E6%AD%A5.jpg)
1. Slave 上面的IO线程连接上 Master,并请求从指定日志文件的指定位置(或者从最开始的日志)之后的日志内容;
2. Master 接收到来自 Slave 的 IO 线程的请求后,通过负责复制的 IO线程根据请求信息读取指定日志指定位置之后的日志信息,返回给 Slave 端的 IO线程。返回信息中除了日志所包含的信息之外,还包括本次返回的信息在 Master 端的 Binary Log 文件的名称以及在 BinaryLog 中的位置;
3. Slave 的 IO 线程接收到信息后,将接收到的日志内容依次写入到 Slave 端的RelayLog文件(mysql-relay-lin.xxxxxx)的最末端,并将读取到的Master端的bin-log的文件名和位置记录到 master-info文件中,以便在下一次读取的时候能够清楚的告诉Master“我需要从某个bin-log的哪个位置开始往后的日志内容,请发给我”
4. Slave 的 SQL 线程检测到 Relay Log 中新增加了内容后,会马上解析该 Log 文件中的内容成为在 Master端真实执行时候的那些可执行的 SQL语句,并在自身执行这些 SQL。实际上就是在 Master 端和 Slave端执行了同样的 SQL,所以两端的数据是完全一样的。
Mysql slave的操作:
Mysql复制状态:
01 | mysql> SHOW SLAVE STATUS\G |
02 | *************************** 1. row *************************** |
03 | Slave_IO_State: Waiting for master to send event |
08 | Master_Log_File: mysql-bin.000001 |
09 | Read_Master_Log_Pos: 164 |
10 | Relay_Log_File: mysql-relay-bin.000001 |
12 | Relay_Master_Log_File: mysql-bin.000001 |
14 | Slave_SQL_Running: Yes |
16 | Seconds_Behind_Master: 0 |
其中,我们最关心的就是:
如果两个中,有一个不是yes,那同步就有问题了。
修复方法:
重试:
有一些因为网络原因断掉的情况,这样就能修复。
跳过错误:
跳过一个错误的事物,也可以跳过多个。
注意,这可能会造成数据不一致。
2 | mysql> set GLOBAL SQL_SLAVE_SKIP_COUNTER=1; |
重定位点:
1.首先停掉Slave服务:slave stop
2.到主服务器上查看主机状态:
记录File和Position对应的值。
1 | mysql> show master status; |
3 | | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | |
5 | | mysql-bin.000020 | 135617781 | | | |
7 | 1 row in set (0.00 sec) |
3.到slave服务器上执行手动同步:
1 | mysql> change master to |
2 | > master_host= 'master_ip' , |
4 | > master_password= 'pwd' , |
6 | > master_log_file= 'mysql-bin.000020' , |
7 | > master_log_pos=135617781; |
8 | 1 row in set (0.00 sec) |
重建备库:
如果主备有表结构不一致,那恐怕只能重做备库了。这里不详细说明。
转载请注明:旅途@KryptosX » MYSQL SLAVE同步修复