为什么我的 Amazon Redshift 集群在维护时段之外重启？

由于以下原因，Amazon Redshift 集群会在维护时段之外重启：

• 检测到您的 Amazon Redshift 集群存在问题。
• 已替换集群中的故障节点。
  

要收到在维护时段之外重启集群的通知，请为 Amazon Redshift 集群创建事件通知。

检测到您的 Amazon Redshift 集群存在问题

以下是可能触发集群重启的一些常见问题：

• 领导节点上出现内存不足 (OOM) 错误：在升级到较新版本的集群上运行查询时，可能会导致 OOM 异常，从而触发集群重启。要解决此问题，请考虑回滚修补程序或失败的修补程序。
• 驱动程序版本较旧导致的 OOM 错误：如果您正在使用较旧的驱动程序版本并且您的集群频繁重启，请下载最新的 JDBC 驱动程序版本。请注意，在生产中使用此驱动程序版本之前，应先在开发环境中进行测试。

已替换 Amazon Redshift 集群中的故障节点

每个 Amazon Redshift 节点都在一个单独的 Amazon Elastic Compute Cloud (Amazon EC2) 实例上运行。故障节点是在监控过程中无法响应发送的任何检测信号的实例。检测信号用于定期监控 Amazon Redshift 集群中计算节点的可用性。

这些自动进行的运行状况检查会尝试在检测到问题时恢复 Amazon Redshift 集群。当 Amazon Redshift 检测到任何硬件问题或故障时，系统会在以下维护时段自动更换节点。请注意，在某些情况下，必须立即更换故障节点，以确保集群正常运行。

以下是集群节点出现故障的一些常见原因：

• EC2 实例故障：当发现 EC2 实例的底层硬件出现故障时，会替换故障节点以恢复集群性能。如果没有响应或未能通过任何自动进行的运行状况检查，EC2 会将底层硬件标记为存在故障。
• 由于节点的磁盘驱动器发生故障而更换节点：当检测到节点上的磁盘出现问题时，Amazon Redshift 会替换磁盘或重启相关节点。如果 Amazon Redshift 集群无法恢复，则会替换或计划替换相关节点。
• 节点间通信失败：如果节点之间通信失败，则特定节点在指定时间不会收到控制消息。节点间通信失败是由于间歇性网络连接问题或底层主机出现问题引起的。
• 发现超时：如果无法在指定时间内到达节点或集群，则会触发自动更换节点。
• 内存不足 (OOM) 异常：特定节点上的负载过重可能会导致 OOM 问题，从而触发节点更换。

创建 Amazon Redshift 事件通知

要确定集群重启的原因，请创建 Amazon Redshift 事件通知，订阅所有集群重启事件。事件通知还会通知您是否已配置源。