mysql> show slave status\G

*************************** 1. row ***************************

Slave_IO_State: Waiting for master to send event

Waiting for master update：连接前的初始状态。

Connecting to master：线程正试图连接到主线程

Checking master version：检查主版本，在连接到主时，发生非常短暂的一种状态。

Registering slave on master：在master上注册slave，在连接到主时，发生非常短暂的一种状态。

Requesting binlog dump：在连接到主时，发生非常短暂的一种状态。线程发送请求其二进制日志的内容的要求，包括二进制日志文件开始名称和位置。

注意，应该是从发送请求主二进制文件名称和位置，然后主发送相应内容。

Waiting to reconnect after a failed binlog dump request：如果二进制日志转储请求失败（由于断开），在休眠期间线程进入这个状态，然后周期性尝试重新连接。

重试之间的间隔可以指定（Connect_Retry）。

Reconnecting after a failed binlog dump request：线程正在尝试重新连接到master

Waiting for master to send event：线程已连接到主线程，等待二进制日志事件到达。如果master的binlog无任何更新，可能持续很长一段时间。

如果等待时间slave_net_timeout秒，超时发生。这时，该线程认为连接被中断，并尝试重新连接。（所以，slave_net_timeout不应该设置太大，以免主从断开连接很久才发现）

Queueing master event to the relay log：线程读取事件并复制到中继日志，SQL线程可以处理它。

Waiting to reconnect after a failed master event read：读取（由于断开）时发生错误。线程正处于休眠状态，等待（Connect_Retry秒），后将继续尝试读取。

Reconnecting after a failed master event read：线程正在尝试重新连接到主线程。当连接再次建立时，状态成为Waiting for master to send event。

Waiting for the slave SQL thread to free enough relay log space：如果设置了的relay_log_space_limit值（即非0），和中继日志总大小足以超过这个值。

I/O线程等待直到SQL线程通过处理中继日志内容释放足够的空间，这样它就可以删除一些中继日志文件。

Waiting for slave mutex on exit：当线程停止时发生的很短暂的状态。

Master_Host: 192.168.10.155

Master_User: repl_user

Master_Port: 3306

Connect_Retry: 60

Connect_Retry：slave知道和master断开连接，并且开始重试的时间间隔，默认60s。Master_Retry_Count限制重试次数，默认3600×24=86400。

值得主意的是：slave是通过slave_net_timeout参数（默认3600s，建议60s）知道和master断开了连接。（slave_net_timeout相当于主从心跳,其实master_heartbeat_period才是心跳，没用过）

Master_Log_File: mysql-bin.000004

slave的IO线程当前已经读取的master的binlog日志文件

Read_Master_Log_Pos: 3944

slave的IO线程当前已经读取的master的binlog日志文件的位置点

Relay_Log_File: mysql-relay-bin.000262

slave的SQL线程当前已经读取和执行的slave的中继日志文件

Relay_Log_Pos: 283

slave的SQL线程当前已经读取和执行的slave的中继日志文件的位置点

Relay_Master_Log_File: mysql-bin.000004

包含了在中继日志文件中被读取的事件的主二进制日志文件的名称

Slave_IO_Running: Yes

5.6的版本，有三个值：NO：MYSQL_SLAVE_NOT_RUN，YES：MYSQL_SLAVE_RUN_CONNECT，Connecting：MYSQL_SLAVE_RUN_NOT_CONNECT

Slave_SQL_Running: Yes

slave的sql线程是否启动

Replicate_Do_DB: 

Replicate_Ignore_DB: 

Replicate_Do_Table: 

Replicate_Ignore_Table: 

Replicate_Wild_Do_Table: 

Replicate_Wild_Ignore_Table: trans%.%

上面的设置都是复制筛选

Last_Errno: 0

Last_Error: 

和Last_SQL_Errno and Last_SQL_Error是同义词，当sql线程执行错误时被设置。恢复时，清除。

Skip_Counter: 0

sql_slave_skip_counter参数的值，代表有多少个事件，slave可以跳过。

Exec_Master_Log_Pos: 3944

sql当前读取和执行的master日志文件位置点

Relay_Log_Space: 619

所有中继日志文件的大小

Until_Condition: None

Until_Log_File: 

Until_Log_Pos: 0

在start slave命令中指定的until_option值

Master_SSL_Allowed: No

Master_SSL_CA_File: 

Master_SSL_CA_Path: 

Master_SSL_Cert: 

Master_SSL_Cipher: 

Master_SSL_Key: 

Master_SSL_Verify_Server_Cert: No

如果用ssl方式连接master，上面参数应该被设定

Seconds_Behind_Master: 0

这个值并不能真正反映主从延迟。它的真正含义是：当前slave的timestamp和正在执行的事件的timestamp（该事件在master发生的时间）的差值，

所以这个值只有当网络十分畅通，主从的时钟的一致的，才有效。

Last_IO_Errno: 0

Last_IO_Error: 

Last_SQL_Errno: 0

Last_SQL_Error: 

Replicate_Ignore_Server_Ids: 

这个参数往往在多主或循环复制的时候设置，如Replicate_Ignore_Server_Ids: 2, 6, 9

IO线程不会读取这些服务器上的日志

Master_Server_Id: 1

master的server id值

Master_UUID: a586daad-9c86-11e5-8a34-005056a60000

master的uuid，有了这个值还需要设置Server_Id？

Master_Info_File: mysql.slave_master_info

master.info的位置

SQL_Delay: 0

slave必须滞后的秒数

SQL_Remaining_Delay: NULL

slave必须滞后的秒数的倒计时

Slave_SQL_Running_State: Slave has read all relay log; waiting for the slave I/O thread to update it

Waiting for the next event in relay log：从中继日志读取事件的初始化状态

Reading event from the relay log：sql线程已经从中继日志中读取事件，使事件可以执行

Making temporary file (append) before replaying LOAD DATA INFILE：线程正在执行LOAD DATA INFILE语句并添加数据到一个临时的包含从该数据中读取行的数据的文件。

Making temporary file (create) before replaying LOAD DATA INFILE：5.3版本之前才有

Slave has read all relay log; waiting for more updates：sql线程已经处理完了在中继日志中的所有事件，等待IO线程向中继日志中写事件。

Waiting for slave mutex on exit：发生在线程停止时的短暂状态

Waiting until MASTER_DELAY seconds after master executed event：sql线程已经读取了日志，但是等待复制延迟失效（change master ...MASTER_DELAY控制）

Killing slave：当发出了stop slave命令时

Waiting for an event from Coordinator：发生在多线程复制，slave worker threads在等待coordinator thread发来的事件

啥的

Master_Retry_Count: 86400

slave和master断开连接之后重试连接的次数，默认3600*24

Master_Bind: 

Last_IO_Error_Timestamp: 

最近一次IO错误发生的时间

Last_SQL_Error_Timestamp: 

最近一次SQL错误发生的时间

Master_SSL_Crl: 

Master_SSL_Crlpath: 

Retrieved_Gtid_Set: 

Executed_Gtid_Set: 

Auto_Position: 0

文章目录
半同步复制参数解析
rpl_semi_sync_master_enabled
rpl_semi_sync_master_timeout
rpl_semi_sync_master_trace_level
rpl_semi_sync_master_wait_for_slave_count
rpl_semi_sync_master_wait_no_slave
rpl_semi_sync_master_wait_point
rpl_semi_sync_slave_enabled
rpl_semi_sync_slave_trace_level

半同步复制参数解析
rpl_semi_sync_master_enabled
控制是否打开半同步复制，这是一个即时生效的参数, 举个例子，如果master因为种种原因无法接受到slave返回的ack信息，导致事务在提交阶段阻塞，手动关闭此参数即可生效。
此参数还有另外的作用就是，在slave丢失，事务等待超时后，半同步状态会自动关闭，但是此参数依然是on的状态，此时当半同步slave恢复后，内部状态会自动切换到半同步模式，其实也有一种手动的方式，就是重新设置此参数为on
mysql> set global rpl_semi_sync_master_enabled=off;
Query OK, 0 rows affected (0.00 sec)

mysql> set global rpl_semi_sync_master_enabled=on;
Query OK, 0 rows affected (0.00 sec)

rpl_semi_sync_master_timeout
等待ack的超时时间，可以动态设置，但是对于处于等待状态的事务无效，如果master因为种种原因无法接受到slave返回的ack信息，处于等待状态，此时如果为了让事务成功提交，将此参数设置为0是不生效的。必须调整rpl_semi_sync_master_enabled参数.

但是这里还有一个疑问，如下

假设开始状态为半同步状态，超时时间为10000秒，此时并没有semisync slave




session1
session2
session3




insert into ashe(name) values(‘aaa’);(waiting)





set global rpl_semi_sync_master_timeout=2000;





insert into ashe(name) values(‘aaa’) ?


如上所示，会是什么样的状态呢？

在session2重新调整超时后，对session1的等待并没有任何影响。但是对后续的session3呢？
其实这里还要分两种情况

1，binlog_order_commits=on

在binlog_order_commits=on的状态时，所有事务提交必须按照写binlog的顺序进行，所以事务3会一直处于等待的状态

2, binlog_order_commits=off

在关闭binlog_order_commits时，事务3可以直接进入等待ack的逻辑中，此时超时时间为为2秒，2秒钟后，超时提交，并且会更新已经接受到的最大binlog文件+pos值，导致session1中的事务直接提交。
rpl_semi_sync_master_trace_level
这是一个日志打印参数，默认即可
The semisynchronous replication debug trace level on the master. Four levels are defined:

1 = general level (for example, time function failures)

16 = detail level (more verbose information)

32 = net wait level (more information about network waits)

64 = function level (information about function entry and exit)

rpl_semi_sync_master_wait_for_slave_count
必须等待多少个slave的ack信息，才可以提交
rpl_semi_sync_master_wait_no_slave
在没有slave时，是否选择等待。


rpl_semi_sync_master_wait_point
控制等待ack的逻辑处于整个事务提交过程的哪个阶段，目前支持两种模式


AFTER_SYNC


AFTER_COMMIT


关于这两点的具体区别，不在这里描述
rpl_semi_sync_slave_enabled
slave半同步的开关
rpl_semi_sync_slave_trace_level
日志相关

Redis 复制
分布式系统中，复制通常是解决单点故障、保障高可用的方式，本文将整理复制时传输延迟的参数。
传输延迟
主从节点如果不是部署在同一台机器上，那么复制时就会产生网络延迟问题。Redis 提供了 repl-disable-tcp-nodelay 参数，用于控制与 Linux 的配置选项 TCP_NODELAY ，之所以想分析下这个参数是因为感觉它不是很好理解，参考的书中用关闭和开启来说明这个参数，不太贴切。
参数含义
disable 本身的含义是“使……失去能力；禁用”，那么这个参数的含义就是是否禁用 TCP_NODELAY 。
参数值为 yes 和 no。

禁用 TCP_NODELAY：no ，不禁用，双重否定等于肯定，即启用 ，TCP_NODELAY=on；

禁用 TCP_NODELAY：yes，就是禁用, TCP_NODELAY=off。

参数默认值
Redis 中这个参数的默认值是“no”，就是不禁用用 TCP_NODELAY。


参数的影响
启用 TCP_NODELAY 时，无网络延迟，主服务器的命令无论大小都会及时发送给从节点，此时会增加网络带宽的消耗。适合主从网络环境良好的场景。
禁用 TCP_NODELAY 时，主从节点的通信会受到网络拥塞控制，Linux 内核会做出一定的优化，如合并较小的 TCP 数据包从而节省带宽。默认发送时间间隔取决 Linux 内核，一般默认为 40 毫秒。适合垮机房部署的情况。
网络拥塞控制
扩散搜索 TCP_NODELAY，补充如下内容：

在网络拥塞控制领域，我们知道有一个非常有名的算法叫做Nagle算法（Nagle algorithm），这是使用它的发明人John Nagle的名字来命名的，John Nagle在1984年首次用这个算法来尝试解决福特汽车公司的网络拥塞问题（RFC 896），该问题的具体描述是：如果我们的应用程序一次产生1个字节的数据，而这个1个字节数据又以网络数据包的形式发送到远端服务器，那么就很容易导致网络由于太多的数据包而过载。比如，当用户使用Telnet连接到远程服务器时，每一次击键操作就会产生1个字节数据，进而发送出去一个数据包，所以，在典型情况下，传送一个只拥有1个字节有效数据的数据包，却要发费40个字节长包头（即ip头20字节+tcp头20字节）的额外开销，这种有效载荷（payload）利用率极其低下的情况被统称之为愚蠢窗口症候群（Silly Window Syndrome）。可以看到，这种情况对于轻负载的网络来说，可能还可以接受，但是对于重负载的网络而言，就极有可能承载不了而轻易的发生拥塞瘫痪。

（引自：https://www.cnblogs.com/wajika/p/6573014.html）

mysql 并行同步原理图如上。

Enhanced Multi-Threaded Slave配置 

要开启enhanced multi-threaded slave其实很简单，只需根据如下设置：

slave

slave-parallel-type=LOGICAL_CLOCK 

slave-parallel-workers=16 

master_info_repository=TABLE 

relay_log_info_repository=TABLE 

relay_log_recovery=ON

并行复制监控

在配置完成后，performance_schema mysql 的性能视图表，增加了以下表， 

方便进行主从同步的性能监控。

root@slave: (performance_schema)>show tables like ‘replication%’; 

+———————————————+ 

| Tables_in_performance_schema (replication%) | 

+———————————————+ 

| replication_applier_configuration           | 

| replication_applier_status                  | 

| replication_applier_status_by_coordinator   | 

| replication_applier_status_by_worker        | 

| replication_connection_configuration        | 

| replication_connection_status               | 

| replication_group_member_stats              | 

| replication_group_members                   | 

+———————————————+ 

8 rows in set (0.01 sec)

参数优化说明：



slave

slave-parallel-type=LOGICAL_CLOCK 

slave-parallel-workers=4

master_info_repository=TABLE 

relay_log_info_repository=TABLE 

relay_log_recovery=ON

slave_parallel_workers 

若将slave_parallel_workers设置为0，则MySQL 5.7退化为原单线程复制， 

但将slave_parallel_workers设置为1，则SQL线程功能转化为coordinator线程， 

但是只有1个worker线程进行回放，也是单线程复制。然而，这两种性能却又有一些的区别，因为多了一次coordinator线程的转发， 

因此slave_parallel_workers=1的性能反而比0还要差，经测试还有20%左右的性能下降，

master_info_repository ,relay_log_info_repository  

两个参数的值有2种设置类型： file,table,

将参数master_info_repostitory设置为TABLE，这样性能可以有50%~80%的提升。

当设置为table 后，之前的文件： 

master.info 

relay-log.info 将被删除消失。 

代之的是两个表，可以在表中进行查询相关信息。。 

mysql.slave_master_info 

mysql.slave_relay_log_info

root@slave: (test)>select * from mysql.slave_master_info\G 

***************** 1. row ***************** 

       Number_of_lines: 25 

       Master_log_name: mysql-bin.000022 

        Master_log_pos: 3901814 

                  Host: 10.20.0.11 

             User_name: repl 

         User_password: 123456 

                  Port: 3001 

         Connect_retry: 60 

           Enabled_ssl: 0 

                Ssl_ca:  

            Ssl_capath:  

              Ssl_cert:  

            Ssl_cipher:  

               Ssl_key:  

Ssl_verify_server_cert: 0 

             Heartbeat: 30 

                  Bind:  

    Ignored_server_ids: 0 

                  Uuid: 403d88ce-f9d6-11e7-a86f-0050563dd912 

           Retry_count: 86400 

               Ssl_crl:  

           Ssl_crlpath:  

 Enabled_auto_position: 0 

          Channel_name:  

           Tls_version:  

1 row in set (0.01 sec)

root@slave: (test)>select * from mysql.slave_relay_log_info\G 

***************** 1. row ***************** 

  Number_of_lines: 7 

   Relay_log_name: /opt/data/mysql/mysql-relay-bin.000002 

    Relay_log_pos: 3902791 

  Master_log_name: mysql-bin.000022 

   Master_log_pos: 3902625 

        Sql_delay: 0 

Number_of_workers: 4 

               Id: 1 

     Channel_name:  

1 row in set (0.15 sec)

2表字段说明请看URL: https://blog.csdn.net/xxj123go/article/details/72828883