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

2 分钟阅读

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

简短描述

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

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

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

解决方法

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

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

**领导节点上出现内存不足（OOM）错误：**在升级到较新版本的集群上运行的查询，可能会导致 OOM 异常，从而启动集群重启。要解决此问题，请考虑回滚修补程序或失败的修补程序。
**驱动程序版本较旧导致的 OOM 错误：**如果您正在使用较旧的驱动程序版本并且您的集群频繁重启，请下载最新的 JDBC 驱动程序版本。在生产中使用此驱动程序版本之前，最好先在开发环境中进行测试。
**运行状况检查查询失败：**Amazon Redshift 持续监控其组件的可用性。当运行状况检查失败时，Amazon Redshift 会启动重启以使集群尽快恢复正常状态。这样做可以减少停机时间。

防止运行状况检查查询失败

当集群有长时间运行的未完成事务时，发生最常见的运行状况检查失败。当 Amazon Redshift 清理与长时间运行的事务相关的内存时，该进程可能会导致集群锁定。为了防止出现这种情况，最佳做法是使用以下查询来监控未结束的事务。

对于长时间未完成的连接，运行以下示例查询：

select s.process as process_id,
       c.remotehost || ':' || c.remoteport as remote_address,
       s.user_name as username,
       s.db_name,
       s.starttime as session_start_time,
       i.starttime as start_query_time,
       datediff(s,i.starttime,getdate())%86400/3600||' hrs '|| 
datediff(s,i.starttime,getdate())%3600/60||' mins ' || 
datediff(s,i.starttime,getdate())%60||' secs 'as running_query_time,
       i.text as query
from stv_sessions s
left join pg_user u on u.usename = s.user_name
left join stl_connection_log c
          on c.pid = s.process
          and c.event = 'authenticated'
left join stv_inflight i
          on u.usesysid = i.userid
          and s.process = i.pid
where username <> 'rdsdb'
order by session_start_time desc;

对于长时间未完成的事务，运行以下示例查询：

select *,datediff(s,txn_start,getdate())/86400||' days '||datediff(s,txn_start,getdate())%86400/3600||' hrs '||datediff(s,txn_start,getdate())%3600/60||' mins '||datediff(s,txn_start,getdate())%60||' secs' from svv_transactions
where lockable_object_type='transactionid' and pid<>pg_backend_pid() order by 3;

获得这些信息后，您可以通过运行以下查询来查看仍未完成的事务：

select * from svl_statementtext where xid = <xid> order by starttime, sequence)

要终止空闲会话并释放连接，请使用 PG_TERMINATE_BACKEND 命令。

已替换 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 事件通知，订阅所有集群重启事件。事件通知还会通知您是否已配置源。