我已经在主从设备之间设置了mysql gtid复制。 有趣的是，我发现几分钟后复制停止工作，我必须使用stop slave并start slave重新启动mysql复制。 谁能告诉我是什么原因造成这个问题？
改变奴隶的主人：
mysql> change master to -> master_host = 'master.com', -> master_user = 'replica', -> master_password = 'password', -> master_port = 3306, -> MASTER_CONNECT_RETRY = 5, -> MASTER_RETRY_COUNT = 0, -> MASTER_AUTO_POSITION=1;
主configuration文件：
[mysqld] user = mysql pid-file = /var/run/mysqld/mysqld.pid socket = /var/run/mysqld/mysqld.sock port = 3306 basedir = /usr datadir = /data/mysql_data tmpdir = /tmp lc-messages-dir = /usr/share/mysql skip-external-locking binlog-format = MIXED interactive_timeout=180 wait_timeout=180 key_buffer = 16M max_allowed_packet = 16M thread_stack = 192K thread_cache_size = 8 myisam-recover = BACKUP max_connections = 300 query_cache_limit = 1M query_cache_size = 16M general_log = 1 log_error = /var/log/mysql/error.log server-id = 1 log_bin = /var/log/mysql/mysql-bin.log log_bin_trust_function_creators = 1 log-slave-updates = true # enable GTID gtid-mode = on enforce-gtid-consistency = true master-info-repository=TABLE relay-log-info-repository=TABLE sync-master-info=1 binlog-checksum=CRC32 master-verify-checksum=1 expire_logs_days = 10 max_binlog_size = 100M
从站configuration：
[mysqld] user = mysql pid-file = /var/run/mysqld/mysqld.pid socket = /var/run/mysqld/mysqld.sock port = 3306 basedir = /usr datadir = /data/mysql_data tmpdir = /data/mysql_data/tmp lc-messages-dir = /usr/share/mysql skip-external-locking binlog-format = MIXED interactive_timeout=180 wait_timeout=180 key_buffer = 16M max_allowed_packet = 16M thread_stack = 192K thread_cache_size = 8 myisam-recover = BACKUP max_connections = 100 query_cache_limit = 1M query_cache_size = 16M general_log = 1 log_error = /var/log/mysql/error.log server-id = 2 log_bin = /var/log/mysql/mysql-bin.log log_bin_trust_function_creators = 1 log-slave-updates = true # enable GTID gtid-mode = on enforce-gtid-consistency = true sync-master-info=1 binlog-checksum=CRC32 master-verify-checksum=1 slave-sql-verify-checksum=1 binlog-rows-query-log_events=1 expire_logs_days = 10 max_binlog_size = 100M
我没有看到任何show slave status的问题，但问题仍然在打扰我。 任何帮助将提前感谢。
SET GLOBAL SLAVE_NET_TIMEOUT = 60; STOP SLAVE; START SLAVE;
你们有理由怀疑这会解决这个问题，因为没有超时似乎正在发生……你也不希望发生这种情况，但这应该仍然是解决scheme。 我会解释。
当复制似乎停止没有错误，IO =是，SQL =是，Seconds_Behind_Master = 0，这意味着挂起的复制连接。 奴隶认为它是连接的，并认为没有新的事件到达。
在MySQL本地asynchronous复制中，从站负责启动与主站的连接，然后其angular色变为被动 – 当复制事件发生时，主站通过该连接自动将复制事件推送到从站，从站7，没有做任何回应。 TCP当然也有，但是主人和奴隶都没有意识到这一点。 在发生复制事件之前，连接只是空闲的，不会发生任何交互。 只要双方都看不到TCP FIN或RSTclosures连接的任何东西，就认为连接已经启动。
如果主站和从站通过任何有状态地处理TCP连接的设备（防火墙，NAT设备，EC2安全组）连接，因为状态通常意味着超时定时器，所以这在低stream量时段中会出现故障。 如果连接空闲时间过长，“networking”（我将用于将事物连接到其他事物的通用术语）将从状态表中删除连接 – 连接被“遗忘”。 十五分钟是一个常见的值。
当发生这样的超时时，networking通常不做任何事情，除了简单地从其内部存储器结构中移除连接。 通常没有发生在电线上。 连接的各方被认为已经放弃了它，或者stream量已经移动到另一个networking，所以正确清除连接内存的设备不会主动尝试通知其他节点连接不再是可行的。
然后，主站下一次发送一个事件，在超时过后，networking可能会通过在主站的方向上重置这个“未知”连接而不是在从站的方向作出响应，因为主站是启动数据包是“未知”连接的一部分。 所以奴隶认为它有联系，而事实上pipe道的另一端没有任何东西。
设置slave_net_timeout以一种明显slave_net_timeout明显的方式解决了这个问题。 非显而易见的是我们特别感兴趣的，而显而易见的就是我们的后备。
当从设备连接到主设备时，会要求主设备发送心跳消息。 心跳是虚拟复制事件，实际上不会写入主站的二进制日志或从站的中继日志。 只有在MASTER_HEARTBEAT_PERIOD秒没有发生真正的复制事件时才会生成它们。
MASTER_HEARTBEAT_PERIOD ，如果没有用CHANGE_MASTER_TO明确设置，则默认为slave_net_timeout / 2 。
因此，设置slave_net_timeout对解决scheme的不明显贡献是，主设备现在将主动发送stream量来保持空闲的连接，每隔30秒（60/2）保持活动状态，其后备是60秒后根本就是，从站会自动断开连接并重新连接到主站 – 实际上就像停止和启动从站一样 – 尽pipe如果连接完好无损，这种情况不会发生，因为主站将发送这些连接心跳需要。
如果这样可以解决你的问题，记住你还需要通过更新my.cnf并重新启动服务器来更改slave_net_timeout – 否则下一次服务器重新启动时会恢复设置，并且MySQL 5.7之前的默认值是3600 。
您也可以简单地将MASTER_HEARTBEAT_PERIOD更改为较小的值，但这只能解决一半的问题。 当连接失败时，从服务器会花费过多的时间来注意它。
不相关：请注意， MASTER_CONNECT_RETRY = 5是太低了。 你想要这么高，否则在停电的情况下，奴隶可能会太快地放弃主人。