AWS MySQL RDS实例变得无响应并自动重新启动

我们有一个AWS MySQL RDS实例，大小约为1.7T。有时它会失去响应，无法执行任何操作

CPU利用率、写入IOPS、读取IOPS、队列深度、写入吞吐量、写入延迟和读取延迟降至零

连接的数量会堆积起来

“显示引擎innodb状态”挂起

rdsadmin的大量查询（每个查询大约25个）处于挂起状态

SELECT count(*) from mysql.rds_replication_status WHERE action = 'reset slave' and master_host is NULL and master_port is NULL GROUP BY action_timestamp,called_by_user,action,mysql_version,master_host,master_port ORDER BY action_timestamp LIMIT 1;

SELECT NAME, VALUE FROM mysql.rds_configuration; 

一段时间后，实例会自动重新启动，并出现以下错误

启动MySQL重启以解决MySQL导致的日志备份问题。请注意，作为此结果的一部分，将在MySQL完成重新启动后执行DB快照

---

问题是什么？这种情况经常发生。有时，出乎意料的是，这种情况也发生在非高峰时段

检查您的db维护窗口时间，我是指您的计划维护发生的时间，并注意此问题发生的时间是定期还是随机

检查mysql错误日志和慢速查询日志

---

如果可能，将可疑问题粘贴到此处

我遇到了相同的问题，并向AWS支持部门提出了一个问题。得到如下解释：

---

RDS监控服务发现有关备份数据库二进制日志的问题，这对于时间点还原（PITR）功能至关重要。为了缓解此问题并避免数据损坏，RDS monitoring重新启动了RDS实例，因此会自动触发重新启动。为了确保没有数据丢失，它拍摄了DB实例的快照

虽然RDS实例是多AZ的，但由于以下原因没有进行故障转移：

Multi-AZ有两个标准： 1-单盒体验，这意味着客户即使在故障切换后也总能找到自己的数据。 2-比单个AZ更高的可用性

因此，当AWS监控服务决定故障切换到备用实例时，这两个条件都必须存在，但在您的情况下，AWS监控服务注意到了一些可能导致故障切换后数据丢失的风险，这就是它决定重新启动而不是故障切换的原因

---

---

希望这有帮助。不过，在过去一周内，我遇到过3次这种情况。

我们通过将实例升级到5.6.34解决了这个问题

你试过向AWS寻求支持吗？是的。他们的回答不是肯定的，因为我们还没有任何支持订阅。您是否正在打开连接、启动事务、执行更新，然后不关闭事务或连接？实际上，这并不限于一个实例。我们在主服务器和从服务器中都观察到这种行为，其中从服务器基本上只有读取负载。根据这些图，我们观察到连接在cpu图下降到零后立即增加。在此期间，日志中没有什么重要内容。此外，在一个实例中，我们关闭了应用程序，终止了所有会话，并等待数据库响应。但数据库拒绝响应，最终发生了自动重启。（某些命令起作用，如KILL和“show open tables”、“show processlist”）您是否检查了计划维护时间，如果itI检查了与事件不一致的维护窗口，是否可以粘贴该时间的show processlist输出。事实上，事件没有任何模式。进程列表包含许多处于“打开表”状态的查询，另外还有以下查询（每个查询25个）从mysql.rds\u replication\u status中选择count（*），其中action='reset slave'，master\u host为NULL，master\u port为NULL，按action\u时间戳分组，用户称为\u，action，mysql\u version，master\u host，主控\u操作的端口顺序\u时间戳限制1；从mysql.rds_配置中选择名称、值；从mysql.rds_配置中选择名称、值；嗨，安舒尔，谢谢你的回复。看起来他们确实给了你一个解释，但他们是否给了你一个解决方案或解决方法来避免/阻止这种情况？在我们的例子中，这几乎每隔一周发生一次。我已经要求过了。等待答复。太好了。请让我们知道进展如何。嗨，安舒尔，AWS就此回复你了吗？