Mysql 主从同步
【注】：此篇内容为作者整理，和官方文档可能有些差异。
(声明：本教程仅供本人学习使用,如有人使用该技术触犯法律与本人无关)
(如果有错误，还希望指出。共同进步)
Mysql 主从同步原理
留坑，后期补全
Mysql 主从同步配置
留坑，后期不全
Mysql 主从同步字段详解
主从同步命令
【注】开启和关闭都在主数据库中执行
# 开启主从同步
mysql> start slave;
# 停止主从同步
mysql> stop slave;
# 查看主从配置参数, 从库和主库参数配置不同
mysql> show slave status\G; 加“\G“是以换行的形式查看，更人性化可读
主从同步参数【从库读取】
[1] Slave_IO_State: # slave(从库)连接到Master(主库)状态
[2] Master_Host: # Mysql主库的IP地址
[3] Master_User: # Mysql主库负责主从复制的用户，创建主从复制的时候建立(需配置reolication slave权限)
[4] Master_Port: # Mysql主库服务器的端口，一般是3306
[5] Connect_Retry: # 连接中断后，重新尝试连接的时间间隔(默认是60s)
[6] Master_Log_File: # 当前I/O线程正在读取的主库服务器二进制日志文件的名称
[7] Read_Master_Log_Pos: # 当前I/O线程正在读取的二进制日志的位置(偏移量，单位是字节)，说明已经同步二进制日志存储容量的多少
[8] Relay_Log_File: # (中继日志)显示Slave的SQL线程当前正在读取和执行的中继日志文件的名称
[9] Relay_Log_Pos: # 当前Slave SQL线程正在读取“中继日志”的位置(同步到中继日子存储容量的多少)
[10] Relay_Master_Log_File: # SQL线程从中继日志中读取到的SQL语句，相对应的主库的SQL语句记录在主库的哪个(binlog)二进制日志中【Relay_Log_File下的Relay_Log_Pos与Relay_Master_Log_File的Exec_Master_Log_Pos一一对应】
[11] Slave_IO_Running: # 显示I/O线程是否是否被启动并成功的连接到主服务器上，成功/失败：Yes/No
[12] Slave_SQL_Running: # 显示SQL线程是否成功启动， 成功/失败：Yes/No
[13] Replicate_Do_DB: # 指定需要同步的数据库
[14] Replicate_Ignore_DB: # 指定不需要同步的数据库
[15] Replicate_Do_Table: # 指定需要同步的表
[16] Replicate_Ignore_Table: # 指定不需要同步的表
[17] Replicate_Wild_Do_Table: # 指定需要同步的原生数据表(多用于解决跨库更新，sql被忽略的情况)
[18] Replicate_Wild_Ignore_Table: # 指定不需要同步的原生数据表(多用于解决跨库更新，sql被忽略的情况)
[19] Last_Errno: # 表示从库(Slave)的SQL线程读取日志参数最后一次的错误数量
[20] Last_Error: # 表示从库(Slave)的SQL线程读取日志参数最后一次的错误信息
【错误数量为0并且消息为空字符串表示没有错误；如果错误消息不是空值，也会在从库的错误日志中作为消息使用】
[21] Skip_Counter: # 显示最近被使用的SQL_SLAVE_SKIP_COUNT的值，用于跳过Slave错误的，SQL_SLAVE_SKIP_COUNT是以event为单位skip(跳过)，直到skip完第N个event所在的event group才停止，对于事务表，一个event group对应一个事务；对于非事务表，一个event group对应一条SQL语句，一个event group中包含多个events.
[22] Exec_Master_Log_Pos: # 表示SQL线程执行的中继日志相对于主库二进制日志偏移量的位置，Read_Master_Log_Pos - Exec_Master_Log_Pos = 当前SQL线程运行的延时(单位：字节)。注意：Relay_Master_Log_File的值是否和Master_Log_File值相等，如果小于Master_Log_File，说明延迟更大。
[23] Relay_Log_Space: # 表示原有的中继日志结合起来的总大小
[24] Until_Condition: # 在start slave语句中指定UNTIL子句，如果没有指定，值为None
# 如果从库正在读取，直到主库的二进制日志的给定位置为止，只为Master
# 如果从库正在读取，直到达到中继日志的给定位置为止，值为Relay
[25] Until_Log_File: # 读取的指定日志的路径
[26] Until_Log_Pos: # 读取的指定日志的读取位置(偏移量)
【*】-------------------------------------------------------------------
【*】如果Slave使用SSL连接的Master，以下就会显示对应的证书和私钥信息
[27] Master_SSL_Allowed: # 允许对主库进行SSL连接，值为Yes
# 不允许对主库进行SSL连接，值为No
# 允许SSL连接，但是从库没有让SSL支持被启用，值为Ignored
[28] Master_SSL_CA_File: # CA证书路径
[29] Master_SSL_CA_Path:
[30] Master_SSL_Cert: # master证书的路径
[31] Master_SSL_Cipher:
[32] Master_SSL_Key: # master密钥的路径
【*】 ----------------------------------------------------------------
[33] Seconds_Behind_Master: # 从库(slave)当前的时间戳和主库(master)记录该事件的时间戳的差值
[34]Master_SSL_Verify_Server_Cert: #
[35] Last_IO_Errno: # 最后一次I/O线程的错误号
[36] Last_IO_Error: # 最后一次I/O线程的错误信息
[37] Last_SQL_Errno: # 最后一次SQL线程的错误号
[38] Last_SQL_Error: # 最后一次SQL线程的错误信息
[39] Replicate_Ignore_Server_Ids: # 主从复制，从库忽略的主库服务器ID号，就是不以这些服务器ID为主库
[40] Master_Server_Id: # 主库服务器ID
[41] Master_UUID: # 主库服务器的UUID号
[42] Master_Info_File: # 从库中保存主库服务器相关信息文件的路径
[43] SQL_Delay: # 一个非负整数，表示秒数，Slave滞后多少秒于Master
[44] SQL_Remaining_Delay: # 当Slave_SQL_Running_State等待，直到MASTER_DELAY秒后，Master执行的事件，此字段包含一个整数，表示有多少秒左右的延迟。在其他时候，这个字段是NULL
[45] Slave_SQL_Running_State: # SQL线程运行状态
[46] Master_Retry_Count: # 连接主库失败最多的重试次数
[47] Master_Bind: # Slave从库在多网络接口的情况下使用，指定用哪一个Slave网络端口连接到Master
[48] Last_IO_Error_Timestamp: # 最后一次I/O线程错误的时间戳
[49] Last_SQL_Error_Timestamp: # 最后一次SQL线程错误的时间戳
[50] Master_SSL_Crl: #
[51] Master_SSL_Crlpath:
[52] Retrieved_Gtid_Set: # 获取到的GTID<I/O线程> | 接收的二进制日志集合，对应IO线程
[53] Executed_Gtid_Set: # 执行过的GTID<SQL线程> | 执行的二进制日志集合，对应SQL下称
[54] Auto_Position: # 记录在GTID模式下是否开启了自动事务校验
[55] Replicate_Rewrite_DB:
[56] Channel_Name: # 多源复制下(5.7支持)，复制通道的名称，可以有多个
[57] Master_TLS_Version:
Slave_IO_State
1) waiting for master update
这是connecting to master状态之前的状态
2) connecting to master
I/O线程正尝试连接到master
3) checking master version
在与master建立连接后，会出现该状态。该状态出现的时间非常短暂。
4) registering slave on master
在与master建立连接后，会出现该状态。该状态出现的时间非常短暂。
5) requesting binlog dump
在与master建立连接后，会出现该状态。该状态出现的时间非常短暂。在这个状态下，I/O线程向master发送请求，请求binlog，位置从指定的binglog 名字和binglog的position位置开始。
6) waiting to reconnect after a failed binlog dump request
如果因为连接断开，导致binglog的请求失败，I/O线程会进入睡眠状态。然后定期尝试重连。尝试重连的时间间隔，可以使用命令"change master to master_connect_trt=X;"改变。
7) reconnecting after a failed binglog dump request
I/O进程正在尝试连接master
8) waiting for master to send event
说明，已经成功连接到master，正等待二进制日志时间的到达。如果master 空闲，这个状态会持续很长时间。如果等待的时间超过了slave_net_timeout(单位是秒)的值，会出现连接超时。在这种状态下，I/O线程会人为连接失败，并开始尝试重连
9) queueing master event to the relay log
此时，I/O线程已经读取了一个event，并复制到了relay log 中。这样SQL 线程可以执行此event
10) waiting to reconnect after a failed master event read
读取时出现的错误(因为连接断开)。在尝试重连之前，I/O线程进入sleep状态，sleep的时间是master_connect_try的值(默认是60秒)
11) reconnecting after a failed master event read
I/O线程正尝试重连master。如果连接建立，状态会变成"waiting for master to send event"
12) waiting for the slave sql thread to free enough relay log space
这是因为设置了relay_log_space_limit，并且relay log的大小已经整张到了最大值。I/O线程正在等待SQL线程通过删除一些relay log，来释放relay log的空间。
13) waiting for slave mutex on exit
I/O线程停止时会出现的状态，出现的时间非常短。
Slave_SQL_Running_State
1) Reading event from the relay log
线程已经从中继日志读取一个事件，可以对事件进行处理了。
2) Has read all relay log; waiting for the slave I/O thread to update it
线程已经处理了中继日志文件中的所有事件，现在正等待I/O线程将新事件写入中继日志。
3) Waiting for slave mutex on exit
线程停止时发生的一个很简单的状态。
扫一扫
1135
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
