mysql集群 查看集群所有信息 查看数据库集群状态

文章目录

• 1. 查看LightDB集群信息、主从节点
• 2. 判断集群健康状态
• 3. 查看集群事件
• 4. 重启主库
• 5. 重启从库
• 6. 主备切换(switchover)
• 7. 主库故障恢复，主节点重新加入作为从节点(rejoin)

• 7.1 什么时候会rejoin失败、如何确定肯定无法rejoin了？无法rejoin的节点如何重新加入？

---

1. 查看LightDB集群信息、主从节点

使用主节点或从节点运行下面的命令查看集群节点信息：

ltcluster -f $LTHOME/etc/ltcluster/ltcluster.conf cluster show

2. 判断集群健康状态

在主节点或从节点运行命令 ltcluster -f $LTHOME/etc/ltcluster/ltcluster.conf cluster show 展示的信息中没有 WARNING ； Status 和 Upstream 字段没有出现 ? 和 ! 符号。

在各个节点运行命令 ltcluster -f $LTHOME/etc/ltcluster/ltcluster.conf node check 展示的各个检查项的均为 OK 。

3. 查看集群事件

可运行 ltcluster -f $LTHOME/etc/ltcluster/ltcluster.conf cluster events 查看集群事件，最新的事件排在最上面，示例结果如下：

4. 重启主库

主库因修改数据库参数或其他原因需要重启，可以按以下步骤操作。(注意: 重启期间数据库不提供服务)

1. 先停止从库的 keepalived（重要） ，在 root 用户下执行以下命令:

# 1. 获得备库keepalived进程pid
cat /var/run/keepalived.pid

# 2. 杀死keepalived进程
kill keepalived_pid

# 3. 确认keepalived进程确实已不存在
ps aux | grep keepalived

2. 主库重启，需要在 lightdb 用户下执行

# 1. 暂停ltclusterd，防止自动failover
ltcluster -f $LTHOME/etc/ltcluster/ltcluster.conf service pause

# 2. 查看集群状态，确认primary的Paused?状态为yes
ltcluster -f $LTHOME/etc/ltcluster/ltcluster.conf service status

# 3. 先断开所有连接到数据库的客户端和应用程序（否则数据库将stop failed），然后停止主库
lt_ctl -D $LTDATA stop  # 默认会回滚所有未断开的连接

# 如果有连接存在导致stop failed，则可以尝试使用
lt_ctl -D $LTDATA stop -m smart

# 如果仍然stop failed，且因条件限制无法或不希望断开所有客户端连接，则可以使用-m immediate强制停止数据库,此方式下没有回滚连接，即强制断开、强制停止，没有完全shutdown，会导致在启动时recovery
lt_ctl -D $LTDATA stop -m immediate

# 4. 等待数据库停止成功，确认步骤3执行结果中出现server stopped信息

# 5. 修改数据库参数，或做其他事情

# 6. 启动主库
lt_ctl -D $LTDATA start

# 7. 等待数据库启动成功，确认步骤6执行结果中出现server started的信息

# 8. 恢复ltclusterd
ltcluster -f $LTHOME/etc/ltcluster/ltcluster.conf service unpause

# 9. 查看集群状态，确认primary的Paused?状态为no
ltcluster -f $LTHOME/etc/ltcluster/ltcluster.conf service status

3. 从库重新启动 keepalived（需root用户）

5. 重启从库

备库因修改数据库参数或其他原因需要重启，可以在 lightdb用户下按以下步骤操作。

# 1. 暂停ltclusterd,防止自动failover
ltcluster -f $LTHOME/etc/ltcluster/ltcluster.conf service pause

# 2. 查看集群状态，确认standby的Paused?字段为yes
ltcluster -f $LTHOME/etc/ltcluster/ltcluster.conf service status

# 3. 先断开所有连接到数据库的客户端和应用程序（否则数据库将stop failed），然后停止备库
lt_ctl -D $LTDATA stop  # 默认会回滚所有未断开的连接

# 如果有连接存在导致stop failed，则可以尝试使用
lt_ctl -D $LTDATA stop -m smart

# 如果仍然stop failed，且因条件限制无法或不希望断开所有客户端连接，则可以使用-m immediate强制停止数据库,此方式下没有回滚连接，即强制断开、强制停止，没有完全shutdown，会导致在启动时recovery
lt_ctl -D $LTDATA stop -m immediate

# 4. 等待数据库停止成功，确认步骤3执行结果中出现server stopped信息

# 5. 修改数据库参数，或做其他事情

# 6. 启动备库
lt_ctl -D $LTDATA start

# 7. 等待数据库启动成功，确认步骤6执行结果中出现server started的信息

# 8. 恢复ltclusterd
ltcluster -f $LTHOME/etc/ltcluster/ltcluster.conf service unpause

# 9. 确认standby的Paused?字段为no
ltcluster -f $LTHOME/etc/ltcluster/ltcluster.conf service status

6. 主备切换(switchover)

在需要维护primary节点时，可做switchover，互换主从角色。switchover操作的内部执行比较复杂，非必要尽量不要执行。

具体操作时，请严格按照下面步骤执行:

1. 主备之间需要有SSH免密访问(LightDB安装时有要求)
2. 尽量减少应用程序的访问
3. 检查主备间的网络状况是否良好，确保有良好的网络
4. 确保当前主备之间没有明显的复制延迟，尤其在集群复制级别较低的情况下(参考 查看主从同步模式与延时 ， 集群复制级别 )
5. 检查等待归档的文件是否有积压, 可通过下面的命令来检查

ltcluster -f $LTHOME/etc/ltcluster/ltcluster.conf node check --archive-ready

确保输出是： OK (0 pending archive ready files) 。
如果是其他输出，则应检查归档进程是否正常。如果归档正常，则可以等待一会儿再试下。

6. 在备机上试运行，使用dry-run试运行switchover命令，查看输出是否有警告和错误

ltcluster -f $LTHOME/etc/ltcluster/ltcluster.conf standby switchover --siblings-follow --dry-run

如果最后一行信息为：prererequisites for executing STANDBY SWITCHOVER are met，则表示成功

7. 在备机上正式执行switchover (打开最详细的日志级别)

ltcluster -f $LTHOME/etc/ltcluster/ltcluster.conf standby switchover --log-level=DEBUG --verbose --siblings-follow

8. 在各节点上查看集群状态，确认各节点执行结果中primary和standby角色确实已互换

ltcluster -f $LTHOME/etc/ltcluster/ltcluster.conf service status

9. 查看paused状态是否为no
   确认Paused列为no (如果switchover过程出现异常，经过处理后，switchover成功, 此时在这一步可能处于yes)

如果为yes，则执行

ltcluster -f $LTHOME/etc/ltcluster/ltcluster.conf service unpause

10. 如果使用同步模式，则需要把新主改成同步模式(和旧主一样)，新备改成local模式
12. 确认VIP是否切换到新的主机上



13. 确认应用程序是否可以正常访问数据库

7. 主库故障恢复，主节点重新加入作为从节点(rejoin)

当主库发生故障（如宕机）failover后，备库会自动提升为新主库，以确保集群继续可用。在原主库修复后， 可以以备机的方式加入集群，使整个集群仍然保持高可用正常状态。

在原主库故障修复后，数据库本身会仍然运行主模式，我们需要执行rejoin命令，rejoin命令会把数据库改为备模式， 并且从新主把最新的WAL日志同步过来，确保数据一致。

后续描述中， 主库 指的是新主库(即原备机提升后的主库), 备库 指的是原主库(发生宕机的节点)。

以下是具体操作步骤:

1. 确认主库是正常运行状态，而备库是停止状态
2. 同步归档日志，把主库的归档日志同步到备库中，归档目录为: $LTHOME/archive 备库中的原有归档日志应备份到其他地方或者删除。
3. 在备库上执行以下命令，检查当前是否满足rejoin条件(注意把命令中的 <primary_host> 替换为主库的ip地址)

# 确认ltclusterd是否启动，若不存在则启动它
ps aux | grep ltcluster
ltclusterd -d -f $LTHOME/etc/ltcluster/ltcluster.conf -p $LTHOME/etc/ltcluster/ltclusterd.pid
ltcluster -f $LTHOME/etc/ltcluster/ltcluster.conf node rejoin -d 'host=<primary_host> dbname=ltcluster user=ltcluster' --verbose --force-rewind --dry-run

确认输出有 INFO: prerequisites for executing NODE JOIN are met 并且无警告或者错误信息。

4. 正式执行rejoin (注意把命令中的 <primary_host> 替换为主库的ip地址)

ltcluster -f $LTHOME/etc/ltcluster/ltcluster.conf node rejoin -d 'host=<primary_host> dbname=ltcluster user=ltcluster' --verbose --force-rewind

7.1 什么时候会rejoin失败、如何确定肯定无法rejoin了？无法rejoin的节点如何重新加入？

如果备机离线时间较久，必要的WAL日志在主上已经被移除，则rejoin会失败。此时需要使用standby clone操作来恢复集群，standby clone的原理是从主上把整个库拷贝过来， 在数据库较大的情况下耗时会比较久。

standby clone的步骤如下：

1. 确认备库LightDB已停止
3. 清空备库归档目录( $LTHOME/archive )下的内容（若有需要，清空前可先备份）



4. clone试运行，将new_primary_host替换为原备，也就是新主的host

ltcluster -h new_primary_host -U ltcluster -d ltcluster -f $LTHOME/etc/ltcluster/ltcluster.conf standby clone --dry-run

4. 确认试运行结果显示 all prerequisites for "standby clone" are met
5. clone实例目录，new_primary_host同上， 如果库比较大，这里执行时间会很长，具体执行时间取决于网络情况和数据量大小 在我们的测试中800G左右的库大概需要一个小时 我们建议采用异步的方式执行这个命令，以避免执行过程中终端意外关闭的影响。 另外我们开启了最详细的日志级别，以便协助定位问题

nohup ltcluster -h new_primary_host -U ltcluster -d ltcluster\
   -f $LTHOME/etc/ltcluster/ltcluster.conf standby clone -F \
   --log-level=DEBUG --verbose            >standby_clone.log  2>&1 &

6. 把主库的归档目录下的所有文件复制到备库的归档目录中($LTHOME/archive)
7. 启动数据库

lt_ctl -D $LTDATA start

8. 重新注册为standby

ltcluster -f $LTHOME/etc/ltcluster/ltcluster.conf standby register -F

9. 确认ltclusterd是否启动，若不存在则启动它

ps aux | grep ltclusterd

ltclusterd -d -f $LTHOME/etc/ltcluster/ltcluster.conf -p $LTHOME/etc/ltcluster/ltclusterd.pid

10. 查看集群状态，确认集群运行正常

ltcluster -f $LTHOME/etc/ltcluster/ltcluster.conf service status

输出要确保没有警告和错误信息