DRSP使用说明
本文档用于指导使用 DRSP ( Disaster recovery switching platform 容灾切换平台)脚本对GoldenDB进行租户之间的数据同步和切换。
概述
本节介绍任务目标、常用术语以及任务说明。
任务目标
本文档用于指导GoldenDB系统双集群同步的使用。
术语说明
- 生产集群:正常情况下对外提供服务的GoldenDB集群(又称租户),用于承接业务操作。
- 灾备集群:正常情况下不提供服务,而是从生产集群复制数据的GoldenDB集群(又称租户),用于提供灾难、应急等场景下的紧急启动能力,代替生产集群提供服务。
- 服务模式:对外提供服务的模式,承接业务操作,提供GoldenDB集群正常功能。
- 只读模式:在DN节点上设置
read_only,只允许执行读语句;DN主备切换时不再产生额外的升主事务;关闭MDS的心跳表和延迟表更新。 - 同步模式:在只读模式的基础上,从对端GoldenDB集群同步数据,包括:DN数据、GTM数据和元数据。
- 正切:指灾难、应急等场景下将灾备集群从同步模式切换至服务模式的流程。
- 回切:指将生产集群和灾备集群恢复至原状态,即生产集群处于服务模式下,对外提供服务,灾备集群处于同步模式下,从生产集群同步数据。
任务说明
整套脚本分为以下几部分:
- 部署脚本:用于部署切换脚本,并向RDB中写入搭建双集群同步所必须的信息。
- 切换脚本:用于提供计划切换、演练切换和故障切换这三种场景下的一键切换功能。
灾备集群安装及集群基础数据恢复说明
本节介绍使用 DRSP 进行数据同步的组网以及环境要求,以及开启GTM数据上传的方法,恢复基础数据的方法。
灾备集群安装说明:
安装灾备集群时,需要满足以下几个条件:
- 灾备集群组网必须与作为同步源的生产集群一致,包括:集群内分片数量、集群内各分片ID、集群模式(即单分片集群或多分片集群)。
- 生产集群、灾备集群的账户密码加密方式(AES加密或国密加密)必须一致。
- 灾备集群内置账户的密码尽量与当前生产集群一致,避免恢复DN数据时元数据中账户密码和DN账户密码不一致的问题。以上所说的账户指DN上的
repl、dbagent、root、dbproxy、super、mds2proxy账户,不包括安装完后手动增加的业务账户。 - 生产集群、灾备集群各组件所在服务器应当时钟同步。
- 灾备集群各组件用户属组的组名和组ID需与生产集群相同。
- 生产集群和灾备集群的删库权限需要保持一致,如果生产允许删库执行,灾备不允许,DN同步会报错。
开启MDS上传GTM数据功能:
需要修改生产、灾备所有MDS的配置文件metadataserver.ini里的LoadGTMDataWaitTime,并且动态生效来开启上传GTM数据。建议填写3000(即5分钟)或6000(即10分钟)。
方式1: 登录生产集群和灾备集群所属的GoldenDB系统的Insight运维界面进行修改。
方式2: 登录生产集群和灾备集群 所有 管理节点,执行dbtool进行修改:
dbtool -cfgini -s ${HOME}/etc/metadataserver.ini Metadataserver LoadGTMDataWaitTime 3000对于当前 主 管理节点,还需要动态加载刚才修改的配置项,执行:
dbtool -mds -lc恢复DN基础数据
恢复DN数据的推荐方式有两种方式,根据现场要求和实际情况选择其一执行即可。如果有多个集群需要进行恢复,修改以上命令中的集群号N,并重复执行多次。
方式1: 使用跨系统集群恢复功能
1.灾备集群进入只读模式,并且禁用集群:
登录灾备集群所属GoldenDB系统的主管理节点,执行:
dbtool -mds -switchworkmode -mode=readonly -clusterid=N如果灾备已经是同步模式,则命令需要加个参数-fault: dbtool -mds -switchworkmode -mode=readonly -clusterid=N -fault
dbtool -mds -disablecluster -clusterid=N2.登录灾备集群所属GoldenDB系统的Insight运维界面,在界面上进行跨系统集群恢复:
恢复级别:实例;数据源:其他系统;一致性回滚:否
3.灾备DN重新设置只读,并且启用集群:
dbtool -mds -drsptask -clusterid=N -task=dnreadonly
dbtool -mds -enablecluster -clusterid=N第一条-task=dnreadonly的命令仅仅在该场景调用,模式切换请勿调用!
方式2: 拷贝DN节点data目录方式恢复DN基础数据
1.灾备集群进入只读模式:
登录灾备集群所属GoldenDB系统的主管理节点,执行:
dbtool -mds -switchworkmode -mode=readonly -clusterid=N如果灾备已经是同步模式,则命令需要加个参数-fault: dbtool -mds -switchworkmode -mode=readonly -clusterid=N -fault
2.检查灾备集群元数据中内置账户密码是否和生产集群一致:
登录生产和灾备RDB,执行:
SELECT clusterid,username,password,encodetype FROM mds.db_passwd_info WHERE accttype=0 AND clusterid=N其中encodetype为加密方式,password为加密后的密文密码。
1)如果完全一致,则跳过此步骤。
2)如果加密方式不一致,则需要重装系统,保持和生产一致。
3)如果加密方式一致,则比较密文密码是否一致,不一致的情况下需要将进行修改:
UPDATE mds.db_passwd_info SET password='XXX' WHERE clusterid=N AND username='XXX'修改后,到灾备集群所属GoldenDB系统的主管理节点上执行以下命令:
dbtool -mds -loadmetadata -clusterid=N -type=user -updateversion=true
dbtool -cm -refresh-passwd -clusterID=N3.从生产各分片挑选一个备机,对data目录进行打包,到灾备集群对应分片的DN上进行恢复。
1)打包生产DN数据。登录挑选的备机DN节点:
dbmoni -stop
tar zcf backup_data.tar.gz data
dbmoni -start2)发送到灾备对应分片,解压:
dbmoni -stop
mv data data_org_bak
tar zxf backup_data.tar.gz
rm data/data/auto.cnf
cp data_org_bak/data/auto.cnf data/data/检查 binlog 、relaylog 的 index 文件内容 和 DN 配置文件中的 log-bin 的配置格式是否一致(全路径|相对路径),不一致请手工修改binlog 、 relaylog 中 index 配置与 DN 配置文件中 log-bin 的配置一致。relaylog 的 index 文件若没有请忽略。
dbmoni -start双集群同步首次搭建
本节介绍第一次搭建 DRSP 的部署。
搭建前准备
1.请先完成第二章说明的灾备集群安装与集群全量数据恢复。
2.检查python和相关库版本:
cd platform/basic
python check_env.py要求版本大于等于以下:
python:2.7.5
requests:2.12.4
kazoo:2.6.1
pymysql:0.9.3
paramiko:1.17.1如果缺少某些库,可以解压产品包并使用init_env.py进行环境初始化,或针对缺少的库进行单独安装。安装需要高权用户。
配置文件填写
解压脚本包,获取所有脚本及配置文件。本文涉及到脚本的操作均在platform目录下: cd drsp/platform
填写以下配置文件,每个配置项在文件中均有填写说明:
config/config.ini配置文件中[general]段为公共配置。其他段中的配置项均为GoldenDB系统信息,一个GoldenDB系统填写一个段的配置,段名可修改,且段名在部署和切换中将会被当作对该GoldenDB系统的标识使用,部署完后不能随意修改。如果有多个GoldenDB系统需要使用 DRSP ,建议填写在同一个配置文件中,添加新的段即可。以下所有的切换等命令中,-source、-dest参数均以类似gdb1、gdb2的格式替代段名(GoldenDB标识),使用时需根据实际配置文件中的段名填写参数。
如果是第一次部署 DRSP ,force_init_metadata_sync_status配置项须填写1;如果是GoldenDB升级后部署新版本 DRSP ,force_init_metadata_sync_status配置项可填0,具体需参考GoldenDB的升级文档。
生成key
该步骤会根据config.ini的zk1_ip生成drsp_key文件,后续部署和切换会实时生成key,并且和该drsp_key文件做一致性校验。多个集群只需要做一次即可:
sh basic/drsp_key.sh -cfg_file=config.ini -action=gen后续如果修改了配置文件config.ini的zk1_ip,需要调用以上命令,重新生成drsp_key文件。
进行脚本部署
将配置好的整个脚本目录拷贝至服务器上,执行命令进行部署:
python basic/deploy.py --config_file config.ini --system_info gdbtag1.cN gdbtag2.cM参数说明:
–config_file 后接config目录下的配置文件名。
–system_info 后可以接多个租户信息,租户信息不区分顺序,不区分生产和灾备,租户信息格式是gdbtag.cN(gdbtag是配置文件里的段名,即GoldenDB标识;N是租户号),多个租户间用空格间隔。
例如:gdb1的租户1作为生产,gdb1的租户2和gdb2的租户3作为灾备接入,并且后续可能进行切换,角色互换,则system_info填入gdb1.c1 gdb1.c2 gdb2.c3,调用一次deploy即可将这3个租户两两之间的同步信息写入RDB,后续切换不再需要部署。
如果有多套不同组网的租户需要部署,则修改system_info并重复执行多次。
灾备集群进入同步模式
登录灾备集群所属的主管理节点,执行命令:
dbtool -mds -switchworkmode -mode=sync -clusterid=N -sourceclusterid=M -sourcetag=gdb1其中N为灾备集群号,M为生产集群号,sourcetag填写生产集群所属GoldenDB的标识(配置文件config.ini里的段名)。如果有多个集群需要部署,则修改集群ID和标识并重复执行多次。
如果不需要做数据恢复,也要先把灾备切到只读模式,才能进入同步模式。
执行成功后,执行命令检查工作模式:
dbtool -mds -printworkmode -clusterid=N一对一同步场景及脚本调用说明
本节介绍一对一复制关系的切换方法。
为方便后续场景及脚本调用说明,假设有两套GoldenDB系统(后续用gdb1和gdb2指代),两套GoldenDB系统中的集群1之间进行数据同步/切换/接管。填写的配置文件为config.ini。以下使用gdb1.c1和gdb2.c1指代两个要进行数据同步和切换的集群。
precheck
每一种类型的切换目录下,都提供了precheck.sh脚本,该脚本用于检查可能影响切换的项目,由于检查项目多,耗时可能长,在切换前提前调用来检查,正式切换的时候可以不调用该脚本。该脚本的调用参数与1_beforecheck.sh一致,即:
sh planswitch/0_precheck.sh -cfg_file=config.ini -source=gdb1 -dest=gdb2 -source_cid=1 -dest_cid=1建议使用独立的precheck脚本进行检测,功能更全。
计划切换
1. 正切
切换前:gdb1.c1处于服务模式,对外提供服务;gdb2.c1处于同步模式,从gdb1.c1同步数据。
切换后:gdb2.c1处于服务模式,对外提供服务;gdb1.c1处于同步模式,从gdb2.c1同步数据。
1)切换前检查
sh planswitch/1_beforecheck.sh -cfg_file=config.ini -source=gdb1 -dest=gdb2 -source_cid=1 -dest_cid=12)切换
前提条件:满足切换前场景,且gdb1.c1上所有业务已停止。
sh planswitch/2_planswitch.sh -cfg_file=config.ini -source=gdb1 -dest=gdb2 -source_cid=1 -dest_cid=13)切换后检查
sh planswitch/3_aftercheck.sh -cfg_file=config.ini -source=gdb1 -dest=gdb2 -source_cid=1 -dest_cid=12. 回切
回切前:gdb2.c1处于服务模式,对外提供服务;gdb1.c1处于同步模式,从gdb2.c1同步数据。
回切后:gdb1.c1处于服务模式,对外提供服务;gdb2.c1处于同步模式,从gdb1.c1同步数据。
1)切换前检查
sh planswitch/1_beforecheck.sh -cfg_file=config.ini -source=gdb2 -dest=gdb1 -source_cid=1 -dest_cid=12)切换
前提条件:满足回切前场景,且gdb2.c1上所有业务已停止。
sh planswitch/2_planswitch.sh -cfg_file=config.ini -source=gdb2 -dest=gdb1 -source_cid=1 -dest_cid=13)切换后检查
sh planswitch/3_aftercheck.sh -cfg_file=config.ini -source=gdb2 -dest=gdb1 -source_cid=1 -dest_cid=1演练切换
如果数据同步是级联的架构,即 gdb1--->gdb2--->gdb3 ,在gdb2做演练切换之前,需要把gdb3断开同步,等gdb2演练结束接入gdb1同步数据后,保证数据字典同步完毕后,再把gdb3接入gdb2继续同步。
1. 灾备启服
切换前:gdb1.c1处于服务模式,对外提供服务;gdb2.c1处于同步模式,从gdb1.c1同步数据。
切换后:gdb1.c1处于服务模式,对外提供服务;gdb2.c1处于服务模式,供演练使用。
gdb2.c1处于服务模式期间,默认禁用业务下发DDL。
如果想要启用DDL,需要修改配置文件config/config.ini的段[general]配置faultsimuswitch_restore_type=2。
该种模式下,演练前会对DN数据进行本地备份,演练结束后会用本地备份的数据恢复DN数据。 备份和恢复都会自动重启DN。
对于元数据则会重置同步起始时间并且清空数据字典表和索引表,重新加载到MDS缓存后 会自动重启CN 。演练结束进入同步后,会进行一次全量元数据同步。
1)切换前检查
sh faultsimuswitch/1_beforecheck.sh -cfg_file=config.ini -source=gdb1 -dest=gdb2 -source_cid=1 -dest_cid=12)切换
sh faultsimuswitch/2_faultsimuswitch.sh -cfg_file=config.ini -source=gdb1 -dest=gdb2 -source_cid=1 -dest_cid=1演练切换时,第2步正切的过程开始阶段,有的局点将集群设置为只读后需要等待并确保下游把日志都追平后才能做一致性回滚。因此,我们把2_faultsimuswitch.sh脚本进行拆分,一个是2_1_quitsync.sh修改集群状态为只读,另一个是2_2_applyandservice.sh该脚本后续的剩余步骤。因此该步骤2_faultsimuswitch.sh和以下2步的效果相同,只需要执行其中一种即可:
sh faultsimuswitch/2_1_quitsync.sh -cfg_file=config.ini -source=gdb1 -dest=gdb2 -source_cid=1 -dest_cid=1sh faultsimuswitch/2_2_applyandservice.sh -cfg_file=config.ini -source=gdb1 -dest=gdb2 -source_cid=1 -dest_cid=13)切换后检查
sh faultsimuswitch/2_faultsimuswitch_aftercheck.sh -cfg_file=config.ini -source=gdb1 -dest=gdb2 -source_cid=1 -dest_cid=12.灾备数据回退
回退前:gdb1.c1处于服务模式,对外提供服务;gdb2.c1处于服务模式,供演练使用。
回退后:gdb1.c1处于服务模式,对外提供服务;gdb2.c1处于停服状态。
前提条件:gdb2.c1上所有业务已停止。
sh faultsimuswitch/3_fastrollback.sh -cfg_file=config.ini -source=gdb1 -dest=gdb2 -source_cid=1 -dest_cid=13.灾备接回生产同步
接入前:gdb1.c1处于服务模式,对外提供服务;gdb2.c1处于停服状态。
接入后:gdb1.c1处于服务模式,对外提供服务;gdb2.c1处于同步模式,从gdb1.c1同步数据。
1)gdb2.c1接入gdb1.c1
sh faultsimuswitch/4_sync.sh -cfg_file=config.ini -source=gdb1 -dest=gdb2 -source_cid=1 -dest_cid=12)切换后检查
sh faultsimuswitch/5_aftercheck.sh -cfg_file=config.ini -source=gdb1 -dest=gdb2 -source_cid=1 -dest_cid=1故障切换
1.灾备启服
切换前:gdb1.c1故障前,gdb1.c1处于服务模式,对外提供服务;gdb2.c1处于同步模式,从gdb1.c1同步数据。gdb1.c1故障后,gdb2.c1同gdb1.c1的同步存在异常。
切换后:gdb1.c1故障;gdb2.c1处于服务模式。
1)切换前检查
sh faultswitch/1_beforecheck.sh -cfg_file=config.ini -source=gdb1 -dest=gdb2 -source_cid=1 -dest_cid=12)切换
sh faultswitch/2_faultswitch.sh -cfg_file=config.ini -source=gdb1 -dest=gdb2 -source_cid=1 -dest_cid=13)切换后检查
sh faultswitch/2_faultswitch_aftercheck.sh -cfg_file=config.ini -source=gdb1 -dest=gdb2 -source_cid=1 -dest_cid=12.生产数据修复
当gdb1.c1故障恢复以后,gdb1.c1和gdb2.c1的数据可能存在差异,需要对gdb1.c1的数据进行分析和修复,请参考《差异化sql和指定gtid set回滚脚本使用说明》文档进行相关操作。
3.生产接入灾备同步
接入前:gdb1.c1故障已恢复,数据为gdb2.c1的子集,处于只读模式;gdb2.c1处于服务模式。
接入后:gdb2.c1处于服务模式,对外提供服务;gdb1.c1处于同步模式,从gdb2.c1同步数据。
该步骤的source和dest和之前的步骤是相反的!
1)gdb1.c1接入gdb2.c1
sh faultswitch/3_sync.sh -cfg_file=config.ini -source=gdb2 -dest=gdb1 -source_cid=1 -dest_cid=12)接入后检查
sh faultswitch/4_aftercheck.sh -cfg_file=config.ini -source=gdb2 -dest=gdb1 -source_cid=1 -dest_cid=14.回切
回切前:gdb2.c1处于服务模式,对外提供服务;gdb1.c1处于同步模式,从gdb2.c1同步数据。
回切后:gdb1.c1处于服务模式,对外提供服务;gdb2.c1处于同步模式,从gdb1.c1同步数据。
脚本调用步骤:回切脚本调用步骤与计划切换的回切一致。
RPO=0的故障切换
生产发生灾难场景,所有数据库进程宕掉(服务功能不可用),但是生产和灾备之间的网络连通,且生产有可用的一致性副本的数据文件或日志文件,此时可以通过生产的数据文件和日志文件,恢复出集群的状态和交易记录,并能将灾备缺失的数据补齐,实现RPO=0。
1.填写配置文件
数据恢复需要依赖5个配置文件,其中前3个由脚本内部自动生成,不需要配置;第4个rdb信息需要手动配置;第5个agent_auth.txt需要手动配置。
对于 RPO=0 故障恢复,如果走IA协议获取生产的数据,目前版本要求生产、灾备的协议类型和rest端口保持一致,如果协议类型不为http或者rest端口不是默认的8021,还需要手动修改以下文件的insightagent_protocol和rest_port:
auto_sync_data_for_remote/gtm/config/conf.ini
auto_sync_data_for_remote/dn/remote_execution/common/config/conf.ini
auto_sync_data_for_remote/rdb/config/conf.ini1)GTM恢复的配置信息
配置文件在drsp/auto_sync_data_for_remote/gtm/cN_gtm_remote_baseinfo.ini
N是灾备的租户ID
2)本地集群组网信息
配置文件在drsp/auto_sync_data_for_remote/dn/cluster_group.ini
3)远端集群组网信息
配置文件在drsp/auto_sync_data_for_remote/dn/cN_gM_remote_baseinfo.ini
N是灾备的租户ID
4)RDB信息
该配置文件需要手动填写,该配置文件在drsp/auto_sync_data_for_remote/rdb/config.ini
目前不支持租户级别的RDB恢复,该步骤在config.ini里是关闭的,恢复数据时会跳过,不填也没关系。
模板参考:drsp/auto_sync_data_for_remote/rdb/config_example.ini
5)agent_auth信息
该配置信息,第一段标识ia所在服务器ip,需要正确配置,否则不能通过ia通道执行命令,该文件所在相对路径:auto_sync_data_for_remote/dn/remote_execution/common/config/agent_auth.txt
2.灾备退出同步模式
切换前:gdb1.c1故障前,gdb1.c1处于服务模式,对外提供服务;gdb2.c1处于同步模式,从gdb1.c1同步数据。gdb1.c1故障后,gdb2.c1同gdb1.c1的同步存在异常。
切换后:gdb1.c1故障;gdb2.c1处于只读模式。
1)切换前检查
sh faultnorbswitch/1_beforecheck.sh -cfg_file=config.ini -source=gdb1 -dest=gdb2 -source_cid=1 -dest_cid=12)灾备退出同步模式
sh faultnorbswitch/2_quit_sync.sh -cfg_file=config.ini -source=gdb1 -dest=gdb2 -source_cid=1 -dest_cid=13.灾备数据恢复
前提条件:gdb2.c1处于只读模式。
脚本调用:
sh faultnorbswitch/3_recover_data_from_remote.sh -cfg_file=config.ini -source=gdb1 -dest=gdb2 -source_cid=1 -dest_cid=1如果问题修复不了,最终数据恢复失败了,依然可以执行下一个脚本继续切换。切换说明请看下一小节。
4.灾备启服
切换前:gdb1.c1故障;gdb2.c1处于只读模式,且已经尝试做了数据恢复。
切换后:gdb1.c1故障;gdb2.c1处于服务模式。
1)切换
sh faultnorbswitch/4_faultnorbswitch.sh -cfg_file=config.ini -source=gdb1 -dest=gdb2 -source_cid=1 -dest_cid=1根据数据恢复的不同情况,切换时内部调用的命令有所区别,由脚本自动判断数据恢复的结果,自动选择切换命令:
(1)DN恢复失败,且config.ini中的配置dn_resotre_failed_continue=no,执行该脚本不会继续切换。如果后续想继续切换,可以把config.ini中的配置dn_resotre_failed_continue改成yes后重新执行脚本4_faultnorbswitch.sh即可继续切换。
(2)DN恢复失败,且config.ini中的配置dn_resotre_failed_continue=yes,该步骤的切换会调用普通的故障切换继续切换。该步骤执行完后,需要从下一小节生产数据修复接着做。
(3)GTM恢复失败,该步骤会应用一次GTM数据,然后使用RPO=0的故障切换继续切换。
(4)RDB恢复失败,该步骤会忽略RDB失败,然后使用RPO=0的故障切换继续切换。
(5)DN/GTM/RDB都恢复成功,该步骤会使用RPO=0的故障切换继续切换。
2)切换后检查
sh faultnorbswitch/4_faultnorbswitch_aftercheck.sh -cfg_file=config.ini -source=gdb1 -dest=gdb2 -source_cid=1 -dest_cid=15.生产数据修复
当gdb1.c1故障恢复以后,gdb1.c1和gdb2.c1的数据可能存在差异,需要对gdb1的数据进行分析和修复,请参考《差异化sql和指定gtid set回滚脚本使用说明》文档进行指定gtid set回滚功能操作。
6.生产接入灾备同步
接入前:gdb1.c1故障已恢复,数据为gdb2.c1的子集,处于只读模式;gdb2.c1处于服务模式。
接入后:gdb2.c1处于服务模式,对外提供服务;gdb1.c1处于同步模式,从gdb2.c1同步数据。
1)gdb1.c1接入gdb2.c1
sh faultnorbswitch/5_sync.sh -cfg_file=config.ini -source=gdb2 -dest=gdb1 -source_cid=1 -dest_cid=12)接入后检查
sh faultnorbswitch/6_aftercheck.sh -cfg_file=config.ini -source=gdb2 -dest=gdb1 -source_cid=1 -dest_cid=17.回切
回切前:gdb2.c1处于服务模式,对外提供服务;gdb1.c1处于同步模式,从gdb2.c1同步数据。
回切后:gdb1.c1处于服务模式,对外提供服务;gdb2.c1处于同步模式,从gdb1.c1同步数据。
脚本调用步骤:回切脚本调用步骤与计划切换的回切一致。
切换中的异常处理
以上所有类型的切换,都需要按顺序执行,不可以跳步骤。必须上一步执行成功,再接着执行下一步。在切换脚本执行时,都会生成日志文件和步骤文件。
日志文件的名称为: 切换脚本名_配置文件名_源GoldenDB系统名_目的GoldenDB系统名_源集群ID_目的集群ID.log
步骤文件的名称为: 切换脚本名_配置文件名_源GoldenDB系统名_目的GoldenDB系统名_源集群ID_目的集群ID_step.txt
如下图所示,具体名称可在打屏输出或日志中看到:
2024-10-16 14:32:55 [INFO] 1_beforecheck.sh(297)
2024-10-16 14:32:55 [INFO] 1_beforecheck.sh(298) -------------------------1_beforecheck begin-------------------------
2024-10-16 14:32:55 [INFO] 1_beforecheck.sh(299) log file: /root/drsp2.1_612.08_61308/platform/planswitch/log/1_beforecheck_config_gdb1_gdb2_1_1.log
2024-10-16 14:32:55 [INFO] 1_beforecheck.sh(320) get sync info FROM rdb
2024-10-16 14:32:56 [INFO] 1_beforecheck.sh(327) success, sync source info match the current cluster.
2024-10-16 14:32:56 [INFO] 1_beforecheck.sh(137) Step 0: begin 1_beforecheck
2024-10-16 14:32:56 [INFO] 1_beforecheck.sh(377) step file: /root/drsp2.1_612.08_61308/platform/planswitch/1_beforecheck_config_gdb1_gdb2_1_1_step.txt
2024-10-16 14:32:56 [INFO] 1_beforecheck.sh(16) Step 1: check source workmode in gdb1.c1
2024-10-16 14:32:56 [INFO] 1_beforecheck.sh(23) Step 1: check source workmode in gdb1.c1 success
2024-10-16 14:32:56 [INFO] 1_beforecheck.sh(28) Step 2: check dest workmode in gdb2.c1
2024-10-16 14:32:57 [INFO] 1_beforecheck.sh(35) Step 2: check dest workmode in gdb2.c1 success
2024-10-16 14:32:57 [INFO] 1_beforecheck.sh(44) Step 3: check dest sync in gdb2.c1
2024-10-16 14:32:57 [INFO] 1_beforecheck.sh(51) Step 3: check dest sync in gdb2.c1 success
2024-10-16 14:32:57 [INFO] 1_beforecheck.sh(54) 1_beforecheck all steps success
2024-10-16 14:32:57 [INFO] 1_beforecheck.sh(56) [~SUCCESS~]脚本执行成功返回0,执行失败返回其他值。如果执行失败,请查看日志文件,根据日志中提示的信息进一步排查、修复问题。 修复完成后可再次执行此脚本重试。 在执行切换脚本的过程中发生了异常,切换流程被迫停止,经人工处理修复后,如果需要再次执行此步骤,则重复执行切换脚本即可;如果需要跳过此步骤,则修改步骤文件中的步骤加1,然后重复执行切换脚本; 如果决定中断此次切换,需要人工处理进行回退。处理完后需人工删除步骤文件。
一对N同步场景及脚本调用说明
本节介绍一对一复制关系的切换方法。
以下以gdbN.cM的格式,指代某一套GoldenDB的集群(租户)M。假设有gdb1、gdb2和gdb3三套GoldenDB系统,同步关系如下:
生产:gdb1.c1
灾备:gdb1.c2、gdb2.c2、gdb3.c3
可以用该脚本查看当前的同步关系:
python drsp/platform/basic/print_topology.py config.ini如果之前没有部署过新生产gdb2.c2和其他灾备(gdb1.c2或gdb3.c3)的信息,则需要在调整同步源之前进行一次部署。如果不确定是否已经部署,可以直接重新部署一下。其中已经正在同步的租户会报错,可以忽略该报错。
进入 DRSP 脚本的platform目录,执行:
python basic/deploy.py --config_file config.ini --system_info gdb1.c1 gdb1.c2 gdb2.c2 gdb3.c3计划切换
1.场景说明:
准备执行计划切换,把生产调整为gdb2.c2,即:
切换前:
生产:gdb1.c1
灾备:gdb1.c2、gdb2.c2、gdb3.c3
切换后:
生产:gdb2.c2
灾备:gdb1.c1、gdb1.c2、gdb3.c3
2.脚本调用步骤:
cd platform/special/
1)预检查切换步骤:
python planswitch_all.py --config-file config.ini --src gdb1.c1 --dest gdb2.c2 --switch-type all --only_print_exec_plan其中gdb1.c1是原生产的信息,gdb2.c2是新生产的信息。
检查切换的步骤应该包括: gdb1.c1和gdb2.c2的计划切换,以及其他灾备gdb1.c2、gdb3.c3的退同步并接入新生产。
2)正式切换:
python planswitch_all.py --config-file config.ini --src gdb1.c1 --dest gdb2.c2 --switch-type all其中gdb1.c1是原生产的信息,gdb2.c2是新生产的信息。
如果切换失败:
情况1:计划切换阶段失败,则解决报错后,可以重试脚本。
情况2:其他灾备退同步并接入新生产失败,如果是某个租户退同步就失败,则解决报错后可以重试。如果是某个租户退同步成功,接入新生产失败,则解决报错后,手动调用命令处理该租户接入新生产。对于没有处理的租户,可以调用脚本接入新生产:
python planswitch_all.py --config-file config.ini --src gdb1.c1 --dest gdb2.c2 --switch-type other故障切换
仅6.1.02.12/6.1.03.09及其以后版本支持,更早的版本请勿使用!
1.场景说明:
准备执行故障切换,把生产调整为gdb2.c2,即:
切换前:
生产:gdb1.c1
灾备:gdb1.c2、gdb2.c2、gdb3.c3
切换后:
生产:gdb2.c2
灾备:gdb1.c2、gdb3.c3
故障:gdb1.c1
2.脚本调用步骤:
cd platform/special/
1)预检查切换步骤:
python faultswitch_all.py --config-file config.ini --src gdb1.c1 --dest gdb2.c2 --switch-type all --switch-other-type switch --no-purge --checkddl --only_print_exec_plan其中gdb1.c1是原生产的信息,gdb2.c2是新生产的信息。
检查切换的步骤应该包括: gdb1.c1和gdb2.c2的故障切换,以及其他灾备gdb1.c2、gdb3.c3的退同步并接入新生产。
故障的gdb1.c1按照本文档4.3.2和4.3.3数据修复后接入新生产gdb2.c2。
2)正式切换:
python faultswitch_all.py --config-file config.ini --src gdb1.c1 --dest gdb2.c2 --switch-type all --switch-other-type switch --no-purge --checkddlgdb1.c1是原生产的信息,gdb2.c2是新生产的信息。
如果切换失败:
情况1:故障切换阶段失败,则解决报错后,可以重试脚本。
情况2:其他灾备退同步并接入新生产失败,如果是某个租户退同步就失败,则解决报错后可以重试。如果是某个租户退同步成功,接入新生产失败,则解决报错后,手动调用命令处理该租户接入新生产。对于没有处理的租户,可以调用脚本接入新生产:
python faultswitch_all.py --config-file config.ini --src gdb1.c1 --dest gdb2.c2 --switch-type other --switch-other-type switch --no-purge --checkddl(3)故障的原生产处理方法和一对一故障切换相同
常用dbtool命令
本节介绍 DRSP 运维常用的dbtool命令。
查看集群工作模式命令
登录GoldenDB系统的主管理节点用户,执行:
dbtool -mds -printworkmode -clusterid=N会打屏输出:Cluster work mode:[MODE]
其中MODE可能有三种:
service —— 服务模式
readonly —— 只读模式
sync —— 同步模式
上述命令中N表示要查询的集群ID。如果填0,则打印所有集群的工作模式。
同步模式下,检查同步状态命令
登录灾备集群所属GoldenDB系统的主管理节点,执行:
dbtool -mds -checksync -clusterid=N该命令会打印元数据、GTM数据和DN数据同步状态。
如果同步状态正常,该dbtool命令返回值为0,并打印success。
输出格式如下:
Send message to module[MetaDataServer,10.229.121.21:6408] localport[5600] pid[94612] successfully!
The response message: RSP Code[0].{0:success; other: fail.}
[10-16 14:37:41:050]Successful response:
Cluster 2,work mode:sync,sync status:
Metadata sync status normal. Current time:2024-10-16 14:37:41 <= [last sync time:2024-10-16 14:37:07] + [sync period:50s] + [tolerance:+20s]
Gtmgtiddata Cluster:2 gtm data sync status normal. Current time:2024-10-16 14:37:41 <= [last sync time:2024-10-16 14:37:19] + [sync period:30s] + [tolerance:+20s]
Gtmseqdata Cluster:2 gtm data sync status normal. Current time:2024-10-16 14:37:41 <= [last sync time:2024-10-16 14:37:19] + [sync period:30s] + [tolerance:+20s]
Group:1,DB [10.229.121.21:5502] details: CurrentTime:2024-10-16 14:37:41,BinlogCurrentTime:2024-10-16 14:37:41,SyncLogTime:2024-10-16 14:37:41,SyncDelayTime:0s,RelayDelayTime:0s.
all master db check replication success. all slave db check replication success.
~success~其中元数据和GTM数据为周期性同步,打印信息中包含检测时间、上一次同步时间、同步周期和容差。当满足:
[当前时间] <= [上一次同步时间] + [同步周期] + [容差]
认为当前同步状态是正常的。
DN数据同步采用主从复制机制,当主从复制关系正常(包括IO和SQL线程正常),且落后时间小于阈值时,认为同步状态正常。
对于单分片集群,不使用GTM,因此将不会打印GTM数据同步状态。输出如下:
Send message to module[MetaDataServer,2108:db81:f101:f101:0:b5dc:fd9a:1014:6408] localport[5600] pid[4005] successfully!
The response message: RSP Code[0].{0:success; other: fail.}
[10-16 14:38:35:740]Successful response:
Cluster 2,work mode:sync,sync status:
Metadata sync status normal. Current time:2024-10-16 14:38:35 <= [last sync time:2024-10-16 14:37:53] + [sync period:120s] + [tolerance:+20s]
Group:1,DB [2108:db81:f101:f101:0:b5dc:fd9a:1014:5503] details: CurrentTime:2024-10-16 14:38:35,BinlogCurrentTime:2024-10-16 00:52:17,SyncLogTime:0,SyncDelayTime:1729011137s,RelayDelayTime:0s.
all master db check replication success. all slave db check replication success.
~success~如果同步状态异常,会打印同步异常的数据,该dbtool返回值非0,打印failure。如下图所示:
Send message to module[MetaDataServer,10.229.121.21:6408] localport[5600] pid[122759] successfully!
The response message: RSP Code[-1].{0:success; other: fail.}
Failure response:
Cluster 1,work mode:service,sync status:
Metadata sync status abnormal. Current time:2024-10-16 14:39:14 > [last sync time:1970-01-01 08:00:00] + [sync period:0s] + [tolerance:+20s]
Gtmgtiddata Cluster:1 gtm data sync status abnormal, decode gtm version info fail!
Gtmseqdata Cluster:1 gtm data sync status abnormal, decode gtm version info fail!
ChangeToProduction:get product master info failed check replication failed!
~failure~如果集群处于非同步模式下,仍然能打印出同步状态,但检查失败并不代表当前集群工作状态异常,仅在特殊场景下具有参考性。
集群工作模式切换命令
执行集群工作模式切换命令需要登录GoldenDB系统的主管理节点,通用格式为:
dbtool -mds -switchworkmode -mode=(service|readonly|sync) -clusterid=N [-sourceclusterid= -sourcetag=] [-plan|-simu|-fault|-delay|-checkddl]做切换尽量使用提供的切换脚本,不要单独调用dbtool进行模式切换,其他情况下慎重使用该dbtool命令。
上述命令中:
N表示需要切换工作模式的集群ID。
-mode=参数后须填写要切换到的工作模式,可填写service、readonly、sync,分别表示服务模式、只读模式和同步模式。只允许[服务模式 -> 只读模式]、[只读模式 -> 服务模式]、[只读模式 -> 同步模式]、[同步模式 -> 只读模式] 四种切换场景。
[-sourceclusterid= -sourcetag=]参数仅在由 只读模式 切换至 同步模式 时需要添加,分别填写同步的数据源端的集群ID和标识。其他模式切换场景下不能添加这两个参数。
[-plan|-simu|-fault|-delay|-checkddl]为额外参数,在部分场景下需要添加该参数。
场景1:计划切换场景下,原生产集群接入灾备集群进行数据同步时,由只读模式切换到同步模式,执行该命令需要添加参数-plan,示例:
dbtool -mds -switchworkmode -mode=sync -clusterid=N -sourceclusterid=M -sourcetag=gdb2 -plan添加该参数的作用是通知MDS查询对端上一次同步元数据的时间,并作为本机进入同步模式后开始同步元数据的起始时间。其他场景进入同步模式不需要添加此参数。
场景2:1对N的故障切换中,其余的灾备接入新生产时,执行该命令时需要添加参数-checkddl
dbtool -mds -switchworkmode -mode=sync -clusterid=N -sourceclusterid=M -sourcetag=gdb2 -checkddl-checkddl:参数仅在由只读模式切换至同步模式时可以添加,进入同步模式时,灾备DN节点会进行回滚多余的数据,进行回滚前检查待回滚的数据中是否有DDL,如果有的话报错,否则继续执行回滚。该参数可选,没有该参数时不检查是否有DDL。
场景3:退出同步模式进入只读模式时,执行该命令必须添加此额外参数。示例:
dbtool -mds -switchworkmode -mode=readonly -clusterid=N (-plan|-simu|-fault|-delay)三种参数区别为:
-plan:等待DN数据同步完全后再断开DN数据同步,断开元数据和GTM数据同步后再触发一次元数据和GTM数据同步,保证这两种数据是最新的。
-simu:立刻断开所有数据同步通道,然后再触发一次元数据和GTM数据同步,保证这两种数据是最新的。
-fault:立刻断开所有数据同步通道。
-delay:立刻断开所有数据同步通道,并且保留relaylog。
应用数据命令
由同步模式切换到只读模式后,需要将同步的数据应用到各节点上。登录GoldenDB系统的主管理节点,执行:
dbtool -mds -applydata -clusterid=N (-plan|-simu|-fault|-fault-no-rollback) [-checkddl]上述命令中,N表示需要应用数据的集群ID。三种额外参数(-plan|-simu|-fault|-fault-no-rollback)的区别为:
-plan:应用元数据、GTM数据和DN数据。
-simu和-fault:应用元数据、GTM数据和DN数据,并且对DN数据进行一致性回滚。
-fault-no-rollback:不应用元数据、GTM数据和DN数据,只是DN持久化gtid set
此外,如果指定的集群为单分片集群,则不会应用GTM数据,也不会对DN数据进行一致性回滚(即使有额外参数-simu或-fault)。
-checkddl:演练和故障切换场景下,DN节点进行一致性回滚前检查待回滚的数据中是否有DDL,如果有的话报错,否则继续执行一致性回滚。该参数可选,没有该参数时不检查是否有DDL。
该命令在灾备切换过程中由脚本自动调用,请尽量避免人为调用此命令。
回放数据命令
由同步模式切换到只读模式后,延迟库的场景需要将同步且未回放的数据回放到指定时间点或者gtid,并且应用到各节点上。登录GoldenDB系统的主管理节点,执行:
dbtool -mds -relaydata -clusterid=N [-time='2024-12-12 12:00:00'] [-gtid=/home/zxmanager/gtid.txt] [-onlycheck]上述命令中,N表示需要应用数据的集群ID。-onlycheck 表示只检查能否回放,不做真正的回放操作。
该命令使用有2种场景:
1.回放到指定时间:
dbtool -mds -relaydata -clusterid=N -time='2024-12-12 12:00:00'2.回放到指定gtid:
dbtool -mds -relaydata -clusterid=N -gtid=/home/zxmanager/gtid.txt该路径需要保证灾备mds有读权限,里面的内容由脚本生成。
修改延迟库的延迟时间
dbtool -mds -drsptask -cid=N -task=modifyrelaydelay 3600延迟时间单位是秒
修改同步源优先级
在需要修改同步源优先级的灾备集群所属GoldenDB系统的主管理节点执行:
dbtool -mds -drsptask -clusterid= -task=modifypriority -sourceclusterid= -sourcetag= -type=0|1|2 -priority=参数说明:
sourceclusterid:生产的DN集群号。
sourcetag:生产的tag,即配置文件config.ini的段名。
type:优先级类型:0-始终同步主DN;1-机房优先级;2-team优先级。
priority:优先级信息:priority_type为0时可不填,1和2时填写机房或teamID。不同优先级使用英文逗号分割,越靠前优先级越高。
查看同步源的信息
在灾备集群所属GoldenDB系统的主管理节点上执行:
dbtool -mds -drsptask -cid=N -task=printsyncinfo其中N是灾备DN集群号。
结果会显示同步源的tag、集群号、zk、RDB、优先级信息。
生产和灾备集群新增分片
本节介绍灾备库场景下,新增分片的方法。
在灾备退同步后,到清理灾备库RDB多余的数据字典结束前(7.3的步骤1),生产不能有DDL。
设置灾备库为只读模式
在灾备主管理节点用户,执行 dbtool -mds -pwm -cid=N ,N为租户集群号。
1.若处于只读模式,则直接跳过本步骤。
2.若处于同步模式:执行 dbtool -mds -switchworkmode -mode=readonly -clusterid=N -simu ,N为租户集群号。
3.若处于服务模式,服务模式为灾备起服场景,不是常用状态,一般不会有新增分片业务,若存在,请联系厂商运维人员处理。
生产集群新增分片
1.在Insight界面正常新增分片即可。
灾备库新增分片
1.删除灾备RDB里已经在生产被删除的库表
IP修改成实际的,N修改成实际的租户ID
#连接生产主RDB执行:
mysql -h10.10.10.10 -P3309 -unormal -p -A -Nse "SELECT name,cluster_id,type,database_name FROM mds.dictionary_info WHERE cluster_id=N order by name">source_dic.dat#连接灾备主RDB执行:
mysql -h10.10.10.11 -P3309 -unormal -p -A -Nse "SELECT name,cluster_id,type,database_name FROM mds.dictionary_info WHERE cluster_id=N order by name">dest_dic.dat#获取在生产已经删除的库表
diff source_dic.dat dest_dic.dat | grep '^> ' | awk '{print "DELETE FROM mds.dictionary_info WHERE cluster_id="$3" AND name=\""$2"\" AND database_name=\"" $5 "\" AND type=" $4 ";" }' > delete_dic.sqlecho "DELETE FROM mds.dictionary_resume_info WHERE cluster_id=N">>delete_dic.sql#检查sql是否正确:
cat delete_dic.sql#连接灾备主RDB执行删除:
mysql -h10.10.10.11 -P3309 -unormal -p -A -Nse "source delete_dic.sql"2.灾备主管理节点动态加载元数据
dbtool -mds -loadmetadata -clusterid=N -type=dict -updateversion=trueN修改成实际的租户ID
3.在Insight界面正常新增分片即可。
4.根据本文恢复DN基础数据方式2,恢复灾备集群新增的分片DN基础数据。
5.如需进入同步模式:执行dbtool -mds -switchworkmode -mode=sync -clusterid=N -sourceclusterid=M -sourcetag=gdb1,N为灾备集群号,M为生产集群号,sourcetag填写生产GoldenDB的标识(配置文件config.ini里的段名)。若保持只读模式, 请忽略此步骤。
gen_config.py使用说明
本节介绍RPO=0故障切换里自动生成配置文件的脚本调用,该脚本的调用已经集成到RPO=0故障切换脚本中自动调用,正常情况下不需要用户自行调用。
usage: gen_config.py [-h] –config_file CONFIG_FILE –system_name SYSTEM_NAME
–zk_root_node {/goldendb_remote,/goldendb_local}
–config_type {gtm,cluster,group}
[–cluster_id CLUSTER_ID [CLUSTER_ID …]]
1.参数说明:
1)CONFIG_FILE 必填,表明使用的是platform/config/CONFIG_FILE该配置文件。填写如 .cluster1_config.ini
2)SYSTEM_NAME 必填,表明使用配置文件里段名[SYSTEM_NAME]下的GoldenDB的信息,此时应该填写灾备的标识,比如gdb2。
3)–zk_root_node 参数值必填,zk的根节点,可填/goldendb_remote 或 /goldendb_local。生成cluster_group.ini的时候需要填/goldendb_local;生成cN_gtm_remote_baseinfo.ini和cN_gM_remote_baseinfo.ini时需要填/goldendb_remote。
4)–config_type 参数值必填,可填gtm,cluster,group其中一个。
5)CLUSTER_ID 选填,可以填1个或多个集群,多个集群之间使用空格隔开,比如1 4 5 6。不提供此参数表示生成所有集群。
2.以下举例具体的调用:
假设当前使用的配置文件名是config.ini;灾备集群所属GoldenDB系统的标识是gdb2;connecttype填入1,即使用用户名和密码。
进入脚本目录:
cd drsp/platform/basic1)生成cN_gtm_remote_baseinfo.ini信息(zk根节点填/goldendb_remote)
python gen_config.py --config_file config.ini --system_name gdb2 --zk_root_node /goldendb_remote --config_type gtm --cluster_id 1 2其中–cluster_id按需要填入cid,不提供此参数表示生成所有集群的信息。生成的配置文件在drsp/auto_sync_data_for_remote/dn目录下。
2)生成cluster_group.ini信息(zk根节点填/goldendb_local,不提供cluster_id参数,生成所有集群的信息)
python gen_config.py --config_file config.ini --system_name gdb2 --zk_root_node /goldendb_local --config_type cluster生成的配置文件在drsp/auto_sync_data_for_remote/dn目录下。
3)生成cN_gM_remote_baseinfo.ini信息(zk根节点填/goldendb_remote)
python gen_config.py --config_file config.ini --system_name gdb2 --zk_root_node /goldendb_remote --config_type group --cluster_id 1 2其中–cluster_id按需要填入cid,不提供此参数表示生成所有集群的信息。生成的配置文件在drsp/auto_sync_data_for_remote/gtm目录下。




