我们在mariadb服务器之间建立了一些复制连接，其中大多数是主从连接（主从版本相同）。有时，但有时，连接似乎停止工作。但是没有错误，IO-和SQL-Running-线程正在运行。在这些情况下，我们只注意到从站上的值丢失，然后我停止并再次启动从站，在此之后，我们将Seconds_behind_master> 0，然后再将其设置为0。 现在，我已经了解了有关变量MASTER_HEARTBEAT_PERIOD的一些信息，但是已使用默认值（30秒）启用了该变量，并且它似乎也不起作用。 这种奇怪行为的原因可能是什么？我们可以做什么？
编辑：经过一番研究（在主服务器和从服务器上发生的预定事件：在主服务器上，它在表中写入了当前时间戳，在从服务器上，它将当前时间戳记与当前时间的差异保存起来）我发现，我们拥有这些从服务器几个小时后定期停止。经过7200秒（2小时）后，从站将再次启动。现在，它在11小时内发生了两次。会是什么？
EDIT2：进一步的调查表明，该现象可能不是由mariadb引起的。我已经监视了一些连接（在我的第一次编辑中进行了介绍），通过这种方式，我发现，只有来自特定主机（MS Hyper-V）的VM的主服务器的复制才会延迟，并且它们绝对延迟同步。我认为，延迟的原因（直到7200秒，然后延迟才会消失）必须在此主机上。 但是-我们在这些VM上的实例也有一些master-master-replication，但是此连接中未出现问题。从其他主机的虚拟机到从属虚拟机上的其他复制连接，我们也没有问题。奇怪。
EDIT3：好吧，这可能不是DNS问题。几天前，我将所有主地址都切换为ip，并设置了skip_no_resolve。但是什么都没有改变。一天中有两次主要时间发生（大约05:58和10:15）。有趣的是，第一次（05:58）相对固定，但是第二次（10:15）每天大约在30秒后（从19.10的10:11到现在的10:19）。而且，也很有趣，晚上27点至28.10点。我们更改了时间（夏令时为+ 1h），第二次更改了（10:15）（在28.10之前是每11:15，现在大约是每10:15）。第一次05:58没变。 并且（我知道，我应该很久以前就这样做了），每隔2个条目，我都在mysql错误日志中：
2018-11-06 10:19:50 6172 [ERROR] Error reading packet from server: Lost connection to MySQL server during query (server_errno=2013)
2018-11-06 10:19:50 6172 [Note] Slave I/O thread: Failed reading log event, reconnecting to retry, log 'mysql-bin.002007' at position 113739713
好吧，有些事情使复制每天停止两次（大约03:58和08:15）而几乎没有错误，几乎相同的时间，但是第二次复制大约每天20-30秒，然后在2小时后mariadb意识到这一点，将这2条消息打印到日志并重新连接从站。我很无助。
答案 0 :(得分：0)
现在我们解决了这个问题。我们将mariadb从10.1.X版本更新到了10.3.7，问题消失了。我们有几个具有不同版本的mariadb实例，并且该问题仅在版本10.1.X上发生，而在所有版本上都没有。而且我仍然认为，延迟的原因来自mariadb外部，但我们仍然不知道，原因可能是什么。但是，现在这不再是我们的问题。更新解决了它。
答案 1 :(得分：0)
有同样的问题。添加：
innodb_flush_log_at_trx_commit = 2
为我解决了MySQL 8.0.13安装上的问题。 在这里阅读：https://dev.mysql.com/doc/refman/8.0/en/innodb-parameters.html#sysvar_innodb_flush_log_at_trx_commit