#主备手动切换
YashanDB支持在主备库同步正常的情况下手动进行主备库的计划内切换（Switchover），也支持在未开启自动选主且主库异常的情况下手动进行备库的故障切换（Failover）。
共享集群部署中，仅备集群的master节点支持手动Switchover切换以及未开启自动选主时手动Failover切换。
Note:
手动执行Switchover或Failover时，新主升主流程分为修改角色前和修改角色后，如果修改数据库角色后流程失败，新主会自动shutdown后尝试重启。
例如XFMR（后台自动转换）模块的启动是在更改角色后执行的，如果启动失败，升主时会自动shutdown后重启。
# 计划内切换Switchover
在日常使用中，需要进行诸如主库所在服务器需进行计划性的维护与升级（例如版本更新、硬件更换、配置调整等）、主库负载较高（可按需手动将流量切换到备库）、模拟测试故障转移能力等操作时，可以按需对数据库执行计划内切换Switchover操作，手动调整主备库角色。
# 注意事项
Switchover过程中，主库已连接的会话将全部断连且不可创建新的会话，直到切换完成或失败。
Switchover过程中，如果主备网络断连，切换将失败。
如果备库transport_lag或apply_lag不为0（即备库有待接收和回放的redo），Switchover过程耗时会增加，可通过查询V$RECOVERY_PROGRESS视图了解剩余回放时间。
Switchover完成后，主备库会重新进行连接，将出现短暂的网络断连。
在逻辑备库上执行switchover时，若执行失败可能会暂停SQL Apply，需执行ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE语句开启SQL Apply。
# 前提条件
主备库同步正常，可通过V$REPLICATION_STATUS视图获取同步状态。
需在备库执行Switchover。
# 操作步骤
以DBA用户连接并登录数据库。
$ yasql sales/********@192.168.1.2:1688 YashanDB SQL Enterprise Edition Release {version_number} x86_64 Connected to: YashanDB Server Enterprise Edition Release {version_number} x86_64 - Linux SQL>确认主备库的角色。
SELECT database_id,database_name,log_mode,open_mode,database_role FROM V$DATABASE; DATABASE_ID DATABASE_NAME LOG_MODE OPEN_MODE DATABASE_ROLE ------------ -------------- ------------- ------------ -------------- 569377301 yashandb ARCHIVELOG READ_ONLY STANDBY若当前节点为主库，需退出会话连接并登录至备库。
检查主备库同步状态。
SELECT connection, status, peer_addr, transport_lag, apply_lag FROM V$REPLICATION_STATUS; CONNECTION STATUS PEER_ADDR TRANSPORT_LAG APPLY_LAG ----------- -------- ---------------------- ------------- ------------ CONNECTED NORMAL 127.0.0.1:1688 0 0在备库中执行Switchover。
此时主库的所有事务将被中断，且Switchover执行过程中客户端无法连接主库。
ALTER DATABASE SWITCHOVER;重复步骤1检查主备库的角色是否已交换以及同步情况是否正常。
# 故障切换Failover
故障切换Failover适用于主库损坏，或者服务器宕机等不可用时，必须立即进行故障切换，尽快恢复业务。
# 步骤1：检查并关闭自选主
在执行Failover切换前，需检查是否开启自选主。若开启，需要在关闭自选后才能执行Failover。
-- 查看参数HA_ELECTION_ENABLED值
SHOW PARAMETER HA_ELECTION_ENABLED
NAME VALUE
---------------------------------------------------------------- ----------------------------------------------------------------
HA_ELECTION_ENABLED TRUE
HA_ELECTION_ENABLED = TRUE表示已开启自动选主，需关闭自动选主后才能执行后续操作。
# 步骤2：选择备库升主
在紧急状态下进行的故障切换可能会丢失数据，为尽可能降低损失，应该在多个备库中选择日志量最多的一个备库执行Failover。
Caution:
Failover可能丢失数据，只能在主库故障的情况下进行，否则可能会出现双主、脑裂（多个节点实例提供写服务）等问题。
Failover完成后，如果旧主库环境恢复，需要对其手动降备，切记不可直接OPEN，否则将出现双主、脑裂等问题。
最大保护模式下，或最大可用模式且同步状态正常的情况下，选择redo最多的备库执行Failover可以更大程度地避免数据丢失。
检查V$REPLICATION_STATUS视图中的received_lfn和gap_seq#字段：
如果gap_seq#都为0，选择received_lfn值最大的备库。
如果某个备库gap_seq#不为0，说明该备库缺少一些归档，升主后将丢失一部分数据，此时需要查看所有备库上的该视图，选择gap_seq#值最大且received_lfn值最大的备库。
-- 确认主备库的角色，为主库或备库 SELECT database_id,database_name,log_mode,open_mode,database_role FROM V$DATABASE; DATABASE_ID DATABASE_NAME LOG_MODE OPEN_MODE DATABASE_ROLE ------------ --------------- ------------ -------------- -------------- 569377301 yasdb ARCHIVELOG READ_ONLY STANDBY -- 确认备库连接已经断连，并且RECEIVED_LFN是剩余备库里最大的，GAP_SEQ#为0 SELECT connection,status,received_lfn,gap_seq# FROM V$REPLICATION_STATUS; CONNECTION STATUS RECEIVED_LFN GAP_SEQ# ----------------- ----------------- --------------------- ------------ DISCONNECTED NORMAL 1420 0在被选定的备库上执行Failover，将备库激活为可读写状态。
ALTER DATABASE FAILOVER;Failover执行成功后，确认备库的角色和open_mode读写模式。
open_mode值为READ_WRITE，database_role值为PRIMARY时，表示Failover操作成功，该备库已被升为新的主库。
SELECT database_id,database_name,log_mode,open_mode,database_role FROM V$DATABASE;
# 步骤3：旧主库降备
Failover完成后，如果旧主库环境恢复，需要对其手动降备。
Warn:
启动旧主库时要严格按照手动降备的流程操作，确保旧主库先只启动到MOUNT阶段并完成降备后再启动至OPEN阶段。
如果选出新主库后，旧主库仍直接启动至OPEN阶段再执行降备操作，可能会导致脑裂现象（即旧主库降为备库后变为NEED REPAIR状态）。
将旧主库实例启动到MOUNT阶段。
# 启动旧主库（例如1-1）到MOUNT阶段 $ yasboot node start -c yashandb -n 1-1 -m mount执行降备命令。
-- 旧主库降备 ALTER DATABASE CONVERT TO PHYSICAL STANDBY;OPEN数据库。
-- OPEN数据库 ALTER DATABASE OPEN; -- 查询角色已经转换 SELECT open_mode,database_role FROM V$DATABASE; OPEN_MODE DATABASE_ROLE ----------------- ----------------- READ_ONLY STANDBY
降备后，查看视图V$REPLICATION_STATUS中的connection和status可以确认新备库状态：
如果连接到了新主库，并且status为NORMAL，说明降备后的新备库状态正常。
如果status为NEED REPAIR，说明发生了脑裂，新旧主库的redo和data有分歧。需要对旧主库进行快速修复或全量修复，具体操作请查阅修复异常备库。
通常情况下，旧主库降备后报NEED REPAIR的可能原因包括：
在最大性能或最大可用模式下，旧主库宕机前存在部分redo暂未发送至备库。备库升主、旧主库降备后，旧主库会比新主库多出此部分redo，若此部分redo中包含已提交事务，则旧主库和新主库数据会不一致，旧主库无法直接作为新主库的备库，需要人工介入修复不一致状态。
在最大保护模式下，若所选备库并非redo最多的，旧主库降备连到新主库时可能报NEED REPAIR，其他备库连到新主库时也可能报NEED REPAIR。因此执行Failover操作时，应尽可能选择redo最多的备库。
如果status为REDO MISMATCH，说明发生了脑裂，新旧主库的redo有分歧。可以使用alter system ignore standby mismatched redo快速修复新备库。
REDO MISMATCH与NEED REPAIR类似，但不一致的redo相对较少且redo内容还未被应用到数据库文件中。因此可以直接丢弃不一致的redo，从分歧点开始接收和应用新主库的redo，实现快速修复。
# yasboot执行主备切换
YashanDB支持通过yasboot工具远端执行yasboot node switchover或yasboot node failover进行主备切换。
下载文档
复制链接
