1、部署管理中心为什么需要6台虚机首先，管理中心在设计的时候有两个平面的：管理面OM、数据面Tenant，两平面是分开的，这需要2个VM简称2VM，推荐在POC阶段使用，而在商用场景时，为保证高可用性，需要引入主备模式，之所以在两个平面各增加2个虚机（总计需要6VM），是因为只有奇数个节点才能完成仲裁机制，防止“脑裂”现象发生。其次,OM与Tenant服务的主备节点部署在数据面3个VM上，但并不意味着指定了某个虚机是做主/备节点使用。当一台虚机宕机时，仲裁机制启用备节点，管理中心仍然可以正常运行。最后，有些服务是采用集群的方式实现的（不是主备方式）例如minio服务，部署在数据面3个节点上。2、为什么需要连接器？连接器是什么？连接器的作用。连接器是一台安装了连接器的助手的电脑，用于远程连接执行器助手的电脑，供无人值守执行器使用。机器人流程在远程Executor上执行自动化操作过程中，如果对象是一个GUI （win32/java swing）程序或者需要截屏、鼠标、键盘操作，需保证远程计算机不能锁屏，连接器就会在无人值守执行器执行任务前，先远程连接至执行器完成屏幕解锁操作。

集群运行过程当中发现有：FI监控页面有主备断连或者不同步告警:编号日志内容1Datanode主备不通过或者断连，重要，xxxxps -ef 查看某一节点上gaussdb进程运行时间与其他实例不同查看集群状态不均衡需要分析主备切换原因。若存在以上情况可按照以下步骤进行分析步骤一：判断是否由于内存不足被oom使用root用户查看/var/log/messages日志在实例重启时间点是否有kill关键字，若存在则说明由于max_process_memory参数设置过大，将参数修改为适当值进行观察，该参数计算方式详细见产品文档。步骤二：是否被cma kill         使用omm用户（云上版本使用Ruby用户）查看cm_agent日志（$GAUSSLOG/cm/cm_agent/cm_agent-xxx.log）在实例重启时间点是否有kill关键字，若存在则说明dn hang或者cm_agent与cm_server连接异常，若该问题偶尔出现一次可不需做任何处理，若出现较为频繁联系华为工程师处理。步骤三：进程core         首先确认该集群是否配置操作系统core，若为配置请先配置操作系统core之后继续观察。core配置方案见附件：GaussDB(DWS) core配置标准方案v1.1         若该集群已经配置core请检查在对应目录检查是否有core文件产生，core文件产生路径查看参考以下命令：cat /proc/sys/kernel/core_pattern，该命令结果为绝对路径直接在对应目录查看，否则在对应重启实例查看。         若产生core文件解析core文件将堆栈反馈给华为工程师进行处理。         若集群集群配置core集群实例多次重启并且不属于步骤一与步骤二的场景，请联系华为工程师处理。

当前 市场上常见的 容灾 模式可分为同城容灾、异地容灾、 双活 数据中心、 两地 三中心几种。1、 同城 容灾同城 容灾 是在同城或相近区域内 （ ≤ 200K M ）建立两个数据中心 : 一个为数据中心，负责日常生产运行 ; 另一个为灾难备份中心，负责在灾难发生后的应用系统运行。同城灾难备份的数据中心与灾难备份中心的距离比较近，通信线路质量较好，比较容易实现数据的同步 复制 ，保证高度的数据完整性和数据零丢失。同城灾难备份一般用于防范火灾、建筑物破坏、供电故障、计算机系统及人为破坏引起的灾难。2、 异地 容灾异地 容灾 主备中心之间的距离较远 （＞ 200KM ) ， 因此一般采用异步镜像，会有少量的数据丢失。异地灾难备份不仅可以防范火灾、建筑物破坏等可能遇到的风险隐患，还能够防范战争、地震、水灾等风险。由于同城灾难备份和异地灾难备份各有所长，为达到最理想的防灾效果，数据中心应考虑采用同城和异地各建立一个灾难备份中心的方式解决。本地容灾 是指在本地机房建立容灾系统，日常情况下可同时分担业务及管理系统的运行，并可切换运行；灾难情况下可在基本不丢失数据的情况下进行灾备应急切换，保持业务连续运行。与异地灾备模式相比较，本地双中心具有投资成本低、建设速度快、运维管理相对简单、可靠性更高等优点；异地灾备中心是指在异地建立一个备份的灾备中心，用于双中心的数据备份，当双中心出现自然灾害等原因而发生故障时，异地灾备中心可以用备份数据进行业务的恢复。本地机房的容灾主要是用于防范生产服务器发生的故障，异地灾备中心用于防范大规模区域性灾难。本地机房的容灾由于其与生产中心处于同一个机房，可通过局域网进行连接，因此数据复制和应用切换比较容易实现，可实现生产与灾备服务器之间数据的实时复制和应用的快速切换。异地灾备中心由于其与生产中心不在同一机房，灾备端与生产端连接的网络线路带宽和质量存在一定的限制，应用系统的切换也需要一定的时间，因此异地灾备中心可以实现在业务限定的时间内进行恢复和可容忍丢失范围内的数据恢复。3、 两地 三中心结合近年国内出现的大范围自然灾害，以同城双中心加异地灾备中心的 “两地三中心”的灾备模式也随之出现，这一方案兼具高可用性和灾难备份的能力。同城双中心 是指在同城或邻近城市建立两个可独立承担关键系统运行的数据中心，双中心具备基本等同的业务处理能力并通过高速链路实时同步数据，日常情况下可同时分担业务及管理系统的运行，并可切换运行；灾难情况下可在基本不丢失数据的情况下进行灾备应急切换，保持业务连续运行。与异地灾备模式相比较，同城双中心具有投资成本低、建设速度快、运维管理相对简单、可靠性更高等优点。异地灾备中心 是指在异地的城市建立一个备份的灾备中心，用于双中心的数据备份，当双中心出现自然灾害等原因而发生故障时，异地灾备中心可以用备份数据进行业务的恢复。两地三中心 ： 是指 同城双中心 加 异地灾备 一种商用容灾备份解决方案；两地 是指同城、异地；三中心 是指生产中心、同城容灾中心、异地容灾中心。（ 生产中心、同城灾备中心、异地 灾备 中心 ）4、 双活 数据中心所谓 “ 双活 ” 或 “ 多 活 ” 数据中心，区别于 传统 数据中心 和 灾备中心的模式，前者 多个 或两个数据中心都处于运行当中， 运行相同的应用，具备同样的数据，能够提供跨中心业务负载均衡运行能力，实现持续的应用可用性和灾难备份能力， 所以称为 “双活 ” 和 “ 多 活 ” ；后者是 生产 数据中心投入运行， 灾备 数据中心处在不工作状态，只有当灾难发生时，生产数据中心瘫痪，灾备中心才启动。“ 双活 ” 数据中心最大的特点是 ： 一、充分利用资源，避免了一个数据中心常年处于闲置状态而造成浪费 ， 通过资源整合， “ 双活 ” 数据中心的服务能力是 翻 倍的 ；   二 、 “ 双活 ” 数据中心如果断了一个数据中心， 其 业务可以 迅速 切换到另外一个 正在 运行的数据中心， 切换 过程对用户来说是不可感知的。在 “ 双活 ” 的模式中，两地数据中心同时接纳交易，技术难度很大，需要更改众多底层程序 ， 因而在现实中，国内还没有 真正 “ 双活 ” 数据中心 的成功 应用 案例。数据容灾技术选择度量标准在构建 容灾 系统时，首先考虑的是结合实际情况选择合理的数据复制技术。 在 选择合理的数据复制技术时主要考虑以下因素：Ø  灾难承受程度 ：明确计算机系统需要承受的灾难类型，系统故障、通信故障、长时间断电、火灾及地震等各种意外情况所采取的备份、保护方案不尽相同。Ø  业务影响程度 ：必须明确当计算机系统发生意外无法工作时，导致业务停顿所造成的损失程度，也就是定义用户对于计算机系统发生故障的最大容忍时间。这是设计备份方案的重要技术指标。Ø  数据保护程度 ：是否要求数据库恢复所有提交的交易 ， 并且要求实时同步 ，保证 数据的连续性和一致性， 这是 备份方案复杂程度的重要依据。对IT企业来说，传统的单数据中心，已不足以保护企业数据的安全。当单数据中心存储故障后，可能会导致业务长时间中断，甚至数据丢失。只做本地的数据冗余保护或容灾建设，已不能规避区域性灾难对企业数据的破坏。远程容灾保护数据及保障企业业务连续性成为了企业亟待解决的问题。另外，企业在远程容灾建设中，也面临网络链路租赁费用高昂和网络带宽不够的问题。2.“两地三中心”的架构实践（1）华为的“基于华为统一存储多级跳复制技术的两地三中心方案”         基于华为统一存储多级跳复制技术，并结合专业的容灾管理软件实现数据的两地三中心保护。该方案在生产中心、同城灾备中心和异地灾备中心分别部署华为OceanStor统一存储设备，通过异步远程复制技术，将生产中的数据复制到同城灾备中心，再到异地灾备中心，实现数据的保护，方案原理组网如图（1）所示。若生产中心发生灾难，可在同城灾备中心实现业务切换，并保持与异地灾备中心的容灾关系；若生产中心和同城灾备中心均发生灾难，可在异地灾备中心实现业务切换。（2）中兴通讯的“基于云计算IaaS和PaaS层面的云计算技术，推出分布式双活数据中心”         中兴的分布式双活数据中心的建设和部署架构如下图所示，在同城建设两个数据中心，同时为外提供业务服务，同时在异地建设灾备中心，用于数据的备份。中兴通讯分布式双活数据中心方案可以帮助客户找到优化投资利用率、保证业务连续性的新思路。

关键字：GaussDB， GTM主备不同步或断连，vacuum full，连接数，分区表场景一：vacuum  full并发高导致GTM连接数不足（8.0及以下版本）1. 查看对应时间点主gtm日志，如果存在以下日志信息，说明gtm线程数满了，导致告警：LOG: Too many threads activieLOG: failed to  add new threadWARNING: create server thread failed2. 查看业务vacuum full并发，按照下面方法估算占用GTM槽位数量是否超过最大值8192：vacuum full 并发数量 *  (CN数量+DN数量)   + 其他业务并发数量 >= 8192这种情况针对大集群比较常见，可以降低vacuum full并发来规避；场景二：GTM故障使用omm用户 登录主备GTM节点，查看GTM进程是否在告警时间点发生过重启：ps -ef|grep gtm如果发生过重启，请联系华为工程师处理

1.    适用场景    多个cn节点内存碎片多等原因需要重启服务器；    多个cn节点由于硬件、网络等因素导致性能下降，成为整个集群的瓶颈，需要隔离。2.    前提条件    被隔离的节点上，不能有任意两个实例在同一个安全环中        cm_ctl query -Cvd|grep 节点1|grep 节点2 不为空时说明两个节点不能同时隔离    故障节点如果有cn，要保证没有业务接入被隔离的cn    故障节点如果有cn，要保证故障节点可以登录，如果多个cn节点故障，并且服务器无法登录，联系华为工程师    至少有一个正常的cn节点、cm_server节点、gtm节点    有lvs，否则需要把业务迁到其他cn    所有操作在沙箱内执行3.    对系统影响隔离节点可能导致整体性能有一定下降，如果本身资源压力已经很大，隔离可能导致业务性能下降明显，这时需业务侧优先执行重要业务，暂停其他业务。4.    隔离多个cn节点4.1停掉节点上所有实例步骤1 以Ruby用户登录沙箱内，集群任意正常节点步骤2 查看要重启的节点编号，以10-185-179-67为例cm_ctl query -Cvd |grep 10-185-179-671  10-185-179-67 6001 /DWS/data1/master1     P Primary Normal | 2  10-185-179-95 6002 /DWS/data1/slave1      S Standby Normal | 3  ASG003        3002 /DWS/data1/dummyslave1 R Secondary Normal步骤3 停掉该节点上所有实例cm_ctl stop -n 1步骤4 其他要隔离的cn节点也按照步骤1-3停止所有实例4.2     手动剔除所有cn步骤1 以Ruby用户登录沙箱内，到每一个被隔离节点，将cn数据目录改名mv /DWS/data1/coordinator /DWS/data1/coordinator_bak步骤2 以Ruby用户登录沙箱内，到任意正常的cn节点，source环境变量，并连接cn，postgres库，password输入dbadmin用户的密码gsql -d postgres -p 8000 -U dbadmin -W password -r步骤3 将所有需要隔离的cn从pgxc_node中删除，并重新建连；with括号中是所有正常的cn。例如，要隔离cn5001和cn5004drop node cn_5001 with (cn_5002,cn_5003);drop node cn_5004 with (cn_5002,cn_5003);select pgxc_pool_reload();步骤8 隔离cn完成，执行DDL语句验证4.3     隔离后恢复步骤1 以Ruby用户登录沙箱内，集群任意正常节点，启动被隔离节点所有实例，将正常的实例都拉起。由于之前修改过cn目录名称，不用担心cn被误拉起cm_ctl start -n 1cm_ctl start -n 4步骤2查看集群状态，如果有实例未能正常拉起，继续执行下一步；如果状态已经恢复为normal，主备均衡后验证业务主备均衡参考 步骤3 如果隔离节点有cm_server，恢复后需确认cm_server状态正常步骤4 对无法拉起的DN实例，分析无法拉起的原因，如果有更换整个raid组等操作导致数据目录受损，则使用gs_replace修复步骤5 节点有cn的情况，使用gs_replace修复cngs_replace操作步骤参考https://bbs.huaweicloud.com/forum/forum.php?mod=viewthread&tid=150101

1.    适用场景集群在运行过程中，出于运维目的数据库管理员可能需要手工对DN或GTM做主备切换。例如发现DN或GTM主备自动failover后想恢复原有的主备角色。2.    前提条件1) DWS集群安装成功，且处于主备不均衡状态。2) 操作时间取得客户同意，并且确认为业务低峰期3) 所有操作在沙箱内执行3.    对系统影响由于过程中会短暂实例服务不可用，故需要选择业务低峰期进行操作，从而减少因数据库主备切换对客户业务的影响。4.    变更步骤4.1检查集群状态处于不均衡状态步骤1 以Ruby用户登录DWS集群的第一个正常的cn节点步骤2 执行以下命令，查看DWS集群当前状态cm_ctl query 结果如下，balanced显示为No，则说明需要进行主备均衡，否则不需要执行此方案[   Cluster State   ] cluster_state  :  Normalredistributing : Nobalanced       : No4.2检查当前为业务低峰期若存在大量业务进行切换时会导致主实例等待业务进程退出长时间无法将备，集群持续不可用，因此执行均衡操作前需要确保处于业务低峰期。步骤1 以Ruby用户登录DWS集群的第一个正常的cn节点步骤2 执行以下命令，查看当前业务情况gsql -d postgres -p 8000 -U dbadmin -W password -c " select * from pgxc_stat_activity where usename!='omm' and state='active'; "如下查询无结果或少于20条记录，则为正常，若大于20条记录联系客户停止当前运行业务或另找业务低峰期进行。coorname | datname | usename | pid | application_name | client_addr | backend_start | xact_start | query_start | state_change | waiting | enqueue | state | query_id | query----------+---------+---------+-----+------------------+-------------+---------------+------------+-------------+--------------+---------+---------+-------+----------+-------(0 rows) 4.3查看是否有主备追赶步骤1 以Ruby用户登录DWS集群的第一个正常的cn节点步骤2 执行以下命令，确保Catchup视图无主备追赶gsql -d postgres -p 8000 -U dbadmin -W password -c "select * from pgxc_get_senders_catchup_time()"如下查询无结果，则为正常nodename | lwpid | local_role | peer_role | state | sender | catchup_start | catchup_end----------+-------+------------+-----------+-------+--------+---------------+-------------(0 rows)如果查询有结果，且结果持续没有变化，并且确认为业务低峰期，则联系华为工程师处理。4.4检查不均衡备DN redo进度 备机需要redo追齐主机才能升主成功，若备机redo进度与当前主实例相差较大执行均衡命令后，需要等备机redo完才能正式成为主机接管业务，在此之前集群持续不可用，因此在切换必须保证主备相差不大，缩短均衡时间。步骤1 以Ruby用户登录DWS集群的第一个正常的cn节点步骤2 执行以下命令，查找不均衡DN实例cm_ctl query -Csdipv结果如下，6001和6002实例发生了主备切换[  Datanode State   ] node     node_ip         instance        state            | node     node_ip         instance        state            ----------------------------------------------------------------------------------------------------------------------1  host1 192.168.0.1  6001 25330      P Standby Normal | 2  host2 192.168.0.2  6002 25490      S Primary Normal当前的主（Primary）实例为6002,6002所在节点为host2，25490为6002进程的端口号步骤 4  登录第一个cn节点创建redo查询视图gsql -d postgres -p 8000 -r -U dbadmin -W password连接到CN执行如下命令创建redo查询视图：CREATE OR REPLACE FUNCTION public.get_redo_info(OUT node_name name, OUT sender_replay_location text, OUT sender_flush_location text, out redoing bool)RETURNS SETOF RECORDLANGUAGE plpgsqlAS $$DECLAREV_SQL text;query_str text;rec record;result record;a text;b text;c text;d text;BEGINV_SQL := 'select node_name from pgxc_node where node_type = ''D'' and hostis_primary = ''f''';FOR rec IN EXECUTE(V_SQL) LOOPquery_str := 'EXECUTE DIRECT ON(' || rec.node_name || ') ''select sender_replay_location,sender_flush_location,receiver_replay_location,receiver_flush_location from pg_stat_get_wal_senders() where peer_role = ''''Standby'''' ''';EXECUTE query_str into result;node_name := rec.node_name;sender_replay_location := result.receiver_replay_location;sender_flush_location := result.receiver_flush_location;a := split_part(sender_replay_location, '/', 1);b := split_part(sender_flush_location, '/', 1);c := split_part(sender_replay_location, '/', 2);d := split_part(sender_flush_location, '/', 2);IF a = b THENredoing = 'f';ELSEredoing = 't';END IF;RETURN NEXT;END LOOP;RETURN;END$$;步骤 5  登录第一个cn节点查询redo进度gsql -d postgres -p 8000 -U dbadmin -W password -c " select * from get_redo_info(); "结果如下，0/1188D4B8为16进制数字，所有实例大小相差不超过10则为正常。  node_name   | sender_replay_location | sender_flush_location | redoing--------------+------------------------+-----------------------+--------- dn_6001_6002 | 0/1188D4B8             | 0/1188D4B8            | f(1 row)如果查询结果，持续相差超过10，并且确认为业务低峰期，则联系华为工程师处理。4.5连接CN执行checkpoint 步骤1 以Ruby用户登录DWS集群的第一个正常的cn节点步骤2 执行以下命令，做checkpointgsql -d postgres -p 8000 -U dbadmin -W password -c "checkpoint"执行结果如下CHECKPOINT若超过5分钟未结束，则联系华为工程师处理。4.6检查当前集群是否有备份任务该步骤只需要在8.1.1(2021年330之后版本)以上版本进行判断，其余版本非均衡情况下不支持备份任务。若当前集群存在备份任务，进行集群均衡会导致备份失败。步骤1 以Ruby用户登录DWS集群的第一个正常的cn节点步骤2 执行以下命令判断是否存在备份任务ps -ef|grep gs_roach|grep -v grep若输出为空则无备份任务，集群进行均衡操作，否则与客户沟通后停止备份集再进行均衡操作。步骤3 执行以下命令，停止备份任务python $GPHOME/script/GaussRoach.py -t stop -F4.7执行主备均衡步骤1 以Ruby用户登录DWS集群的第一个cn节点步骤2 使用如下命令进行主备均衡cm_ctl switchover -a结果如下，则为正常cm_ctl: cmserver is rebalancing the cluster automatically.....cm_ctl: switchover successfully.4.8均衡操作是否成功1)后台集群状态验证步骤1 以Ruby用户登录DWS集群的第一个正常的cn节点步骤2 执行以下命令，查看DWS集群当前状态cm_ctl query如下则为正常[   Cluster State   ] cluster_state  :  Normalredistributing : Nobalanced       : Yes2)客户业务验证验证方案需包括DDL和DML语句

1.    适用场景当主机发生故障状态异常时，用户可能需要停止主机上的所有角色，对主机进行维护检查。故障清除后，启动主机上的所有角色恢复主机业务。2.    前提条件DWS集群安装成功，且处于已启动状态。所有操作在沙箱内执行。3.    对系统影响停止集群前需要用户先停止数据库相关业务，从而避免因数据库停止对客户业务的影响。4.    实施步骤4.1停止集群步骤1 以Ruby用户登录DWS集群的第一个正常的cn节点步骤2 执行以下命令3次，设置检查点，防止集群重新启动后主实例长时间redo引起集群启动较慢。gsql -p 8000 -d postgres -U dbadmin -W password -c "checkpoint"执行结果如下，则为正常CHECKPOINT步骤3 执行以下命令，停止集群cm_ctl stop -mi 执行结果如下：cm_ctl: stop cluster.cm_ctl: stop nodeid: 1cm_ctl: stop nodeid: 2cm_ctl: stop nodeid: 3............cm_ctl: stop cluster successfully.4.3集群维护工作本步骤需结合具体方案目的实施，待集群成功停止后，可以开始进行停集群维护操作，如更换磁盘，升级网卡，下电服务器等。4.4启动集群步骤1 以Ruby用户登录DWS集群的第一个正常的cn节点步骤2 执行以下命令，启动集群cm_ctl start -t 600 执行结果如下：cm_ctl: checking cluster statuscm_ctl: check finished in 247 ms.cm_ctl: start cluster.cm_ctl: start nodeid: 1cm_ctl: start nodeid: 2cm_ctl: start nodeid: 3........................................cm_ctl: start cluster successfully.4.5检查集群状态是否正常步骤1 以Ruby用户登录DWS集群的第一个CN节点步骤2 执行以下命令，确保集群状态正常cm_ctl query如下则为正常[   Cluster State   ]cluster_state  :  Normalredistributing : Nobalanced       : Yes步骤4 确认集群状态是否正常。如果发生主备切换，则需要切回主备（具体参考主备切换标准方案） https://bbs.huaweicloud.com/forum/thread-150166-1-1.html

业务容灾项目：源端业务故障后，容灾切换到华为云灾备端，源端业务恢复，再切回，这样的业务过程中，使用的是华为云DRS同步数据库，问题：源端恢复后，切回时 DRS的主备倒换可以实现吗？需要做反向同步数据的。

一.本案例适合什么场景？网卡光口不通导致服务器宕机二.问题分析1.修复硬件，启动服务器2.硬件修复的节点，dn被拉起后，开始catchup3.等待catchup完成后，进行主备均衡4.主备均衡参考标准方案https://bbs.huaweicloud.com/forum/forum.php?mod=viewthread&tid=145786

诉求场景服务器都在西南贵阳一区域，想在云上做异地灾备，在贵阳一备份成功后，将相关备份在北京四也生成一份，这样贵阳一如果出了问题，北京四也可以保留相关数据。处理思路想实现此功能，要借助备份策略和复制策略两种策略实现，即先按时创建出备份，再将该备份通过复制任务复制到北京四的灾备区域。操作指导1、准备一个贵阳一备份存储库，在此实践中命名为“CBR-存储库”，类型为“备份”：2、给“CBR-存储库”绑定服务器，点击存储库名称，之后选择绑定服务器选项进行绑定：3、在贵阳一创建备份策略，按照实际业务需求配置策略，本次操作中配置策略如下，仅供参考：4、给“CBR-存储库”绑定步骤3创建的策略，操作如截图所述：5、在北京四创建复制存储库，注意不是备份存储库，是复制存储库，即类型是“复制”而不是“备份”：6、回到贵阳一区，在策略选项中切换到复制策略页面，创建复制策略：”本次操作中配置策略如下，请参考：创建此策略时注意，尽量在确保备份策略执行完毕，备份任务已完成后，再执行复制策略，否则可能会出现复制备份失败的情况。7、复制策略创建完成之后，在贵阳一区域找到原来的“CBR-存储库”，绑定复制策略，如图：8、复制策略选择步骤5创建的复制策略，目标存储库选择步骤4您在北京四创建的复制存储库，之后点击“确定”，即可完成配置：9.进行效果验证到指定时间点之后，系统会自动按照复制策略进行复制任务在北京四区域生成对应备份副本

1.    适用场景    多个cn节点内存碎片多等原因需要重启服务器；    多个cn节点由于硬件、网络等因素导致性能下降，成为整个集群的瓶颈，需要隔离。2.    前提条件    被隔离的节点上，不能有任意两个实例在同一个安全环中        cm_ctl query -Cvd|grep 节点1|grep 节点2 不为空时说明两个节点不能同时隔离    故障节点如果有cn，要保证没有业务接入被隔离的cn    故障节点如果有cn，要保证故障节点可以登录，如果多个cn节点故障，并且服务器无法登录，联系华为工程师    至少有一个正常的cn节点、cm_server节点、gtm节点    集群要有lvs，否则需要把业务迁到其他cn3.    对系统影响    隔离节点可能导致整体性能有一定下降，如果本身资源压力已经很大，隔离可能导致业务性能下降明显，这时需业务侧优先执行重要业务，暂停其他业务。    DN被隔离之后，主从DN的xlog不回收，在恢复之前需要持续观察磁盘空间4.    隔离多个cn节点4.1停掉节点上所有实例步骤1 以omm用户登录集群内任意正常节点步骤2 执行以下命令，启用环境变量source ${BIGDATA_HOME}/mppdb/.mppdbgs_profile步骤3 查看要重启的节点编号，以10-185-179-67为例cm_ctl query -Cvd |grep 10-185-179-671  10-185-179-67 6001 /srv/BigData/mppdb/data1/master1     P Primary Normal | 2  10-185-179-95 6002 /srv/BigData/mppdb/data1/slave1      S Standby Normal | 3  ASG003        3002 /srv/BigData/mppdb/data1/dummyslave1 R Secondary Normal步骤4 停掉该节点上所有实例cm_ctl stop -n 1步骤5 其他要隔离的cn节点也按照步骤1-4停止所有实例4.2     手动剔除所有cn步骤1 以omm用户登录每一个被隔离节点，将cn数据目录改名mv /srv/BigData/mppdb/data1/coordinator /srv/BigData/mppdb/data1/coordinator_bak步骤2 以omm用户登录任意正常的cn节点，source环境变量，并连接cn，postgres库gsql -d postgres -p 25308 -r步骤3 将所有需要隔离的cn从pgxc_node中删除，并重新建连；with括号中是所有正常的cn。例如，要隔离cn5001和cn5004drop node cn_5001 with (cn_5002,cn_5003);drop node cn_5004 with (cn_5002,cn_5003);select pgxc_pool_reload();步骤8 隔离cn完成，执行DDL语句验证4.3     隔离后恢复步骤1 以omm用户登录任意正常节点，启动被隔离节点所有实例，将正常的实例都拉起。由于之前修改过cn目录名称，不用担心cn被误拉起cm_ctl start -n 1cm_ctl start -n 4步骤2查看集群状态，如果有实例未能正常拉起，继续执行下一步；如果状态已经恢复为normal，主备均衡后验证主备均衡参考https://bbs.huaweicloud.com/forum/forum.php?mod=viewthread&tid=145786步骤3 如果隔离节点有cm_server，恢复后需确认cm_server状态正常步骤4 对无法拉起的DN实例，分析无法拉起的原因，如果有更换整个raid组等操作导致数据目录受损，则使用gs_replace修复步骤5 节点有cn的情况，使用gs_replace修复cngs_replace操作步骤参考https://bbs.huaweicloud.com/forum/thread-145788-1-1.html

1.    适用场景    单节点内存碎片多等原因需要重启服务器；    服务器hung死需要强制下电重启服务器；    单节点由于硬件、网络等因素导致性能下降，成为整个集群的瓶颈，需要隔离单节点。2.    前提条件    如果故障节点有cn，重启之前需要关闭cn自动剔除功能    如果隔离多个节点，被隔离的节点上，不能有任意两个实例在同一个安全环中    隔离的节点中最多只有一个cn节点    如果故障节点有cn，确保不会有业务接入被隔离的cn    至少有一个正常的cn节点、cm_server节点、gtm节点    有lvs，否则需要把业务迁到其他cn    如果存在磁盘空间超过75%的盘，知会L33.    对系统影响    重启节点会造成业务闪断，业务侧有重试或者集群开启cn_retry的情况下，业务不会感知到报错，但是会感知到执行时间变长    重启的节点上如果有cn，重启过程中DDL语句会被阻塞。    隔离节点可能导致整体性能有一定下降，如果本身资源压力已经很大，隔离可能导致业务性能下降明显，这时需业务侧优先执行重要业务，暂停其他业务。    DN被隔离之后，主从DN的xlog不回收，在恢复之前需要持续观察磁盘空间    重启或隔离恢复后，实例会自动触发catchup，此阶段可能抢占io影响业务，因此重启或隔离后的恢复动作建议放到业务低峰期执行4.    重启单节点4.1关闭cn自动剔除参数（有cn时做）步骤1 以omm用户登录集群内任意正常节点步骤2 执行以下命令，启用环境变量source ${BIGDATA_HOME}/mppdb/.mppdbgs_profile步骤3 关闭cn自动剔除参数gs_guc reload -Z cmserver -N all -I all -c "coordinator_heartbeat_timeout=0"4.2重启节点步骤1 以omm用户登录集群内任意正常的cn节点步骤2 执行以下命令，启用环境变量source ${BIGDATA_HOME}/mppdb/.mppdbgs_profile步骤3 查看要重启的节点编号，以10-185-179-67为例cm_ctl query -Cvd |grep 10-185-179-671  10-185-179-67 6001 /srv/BigData/mppdb/data1/master1     P Primary Normal | 2  10-185-179-95 6002 /srv/BigData/mppdb/data1/slave1      S Standby Normal | 3  ASG003        3002 /srv/BigData/mppdb/data1/dummyslave1 R Secondary Normal步骤4 登录cn数据库，执行checkpointgsql -d postgres -p 25308 –rcheckpoint;步骤5 停掉该节点上所有实例如果是服务器hung死的场景，则跳过步骤5和步骤7，直接下电重启服务器，重启后等待实例自恢复cm_ctl stop -n 1步骤6 重启服务器步骤7 将该节点的实例拉起cm_ctl start -n 1步骤8 主备均衡https://bbs.huaweicloud.com/forum/forum.php?mod=viewthread&tid=145786步骤9 验证集群状态和业务4.2恢复cn自动剔除参数（有cn时做）根据客户需求决定恢复为0或者600s步骤1 以omm用户登录集群内任意正常节点步骤2 执行以下命令，启用环境变量source ${BIGDATA_HOME}/mppdb/.mppdbgs_profile步骤3 恢复cn自动剔除参数gs_guc reload -Z cmserver -N all -I all -c "coordinator_heartbeat_timeout=600"5.    隔离单节点5.1停掉节点上所有实例步骤1 以omm用户登录集群内任意正常节点步骤2 执行以下命令，启用环境变量source ${BIGDATA_HOME}/mppdb/.mppdbgs_profile步骤3 查看要重启的节点编号，以10-185-179-67为例cm_ctl query -Cvd |grep 10-185-179-671  10-185-179-67 6001 /srv/BigData/mppdb/data1/master1     P Primary Normal | 2  10-185-179-95 6002 /srv/BigData/mppdb/data1/slave1      S Standby Normal | 3  ASG003        3002 /srv/BigData/mppdb/data1/dummyslave1 R Secondary Normal步骤4 停掉该节点上所有实例cm_ctl stop -n 15.2     cn自动剔除（节点有cn时做）步骤1 以omm用户登录被隔离节点，将cn数据目录改名如果服务器已经无法登录，可以跳过步骤1mv /srv/BigData/mppdb/data1/coordinator /srv/BigData/mppdb/data1/coordinator_bak步骤2 使用omm用户切换到任意正常节点，source环境变量，设置cn自动剔除参数为60sgs_guc reload -Z cmserver -N all -I all -c "coordinator_heartbeat_timeout=60"步骤3 等待60s后，查看集群状态，被剔除的cn已经变成deleted步骤4 隔离完成，执行DDL语句验证步骤5 根据客户需求将coordinator_heartbeat_timeout设置为0或600s5.3     隔离后恢复步骤1 以omm用户登录任意正常节点，启动被隔离节点所有实例，将正常的实例都拉起。（有cn时，由于之前修改过cn目录名称，不用担心cn被误拉起）cm_ctl start -n 1步骤2 查看集群状态，如果有实例未能正常拉起，继续执行下一步；如果状态已经恢复为normal，主备均衡后验证主备均衡参考https://bbs.huaweicloud.com/forum/forum.php?mod=viewthread&tid=145786步骤3 如果隔离节点有cm_server，恢复后需确认cm_server状态正常步骤4 对无法拉起的DN实例，分析无法拉起的原因，如果有更换整个raid组等操作导致数据目录受损，则使用gs_replace修复步骤5 节点有cn的情况，使用gs_replace修复cngs_replace操作步骤参考https://bbs.huaweicloud.com/forum/thread-145788-1-1.html 

1.    适用场景当主机发生故障状态异常时，用户可能需要停止主机上的所有角色，对主机进行维护检查。故障清除后，启动主机上的所有角色恢复主机业务。2.    前提条件GaussDB A集群安装成功，且处于已启动状态。3.    对系统影响停止集群前需要用户先停止数据库相关业务，从而避免因数据库停止对客户业务的影响。4.    实施步骤4.1预估重启后实例catchup时间8.0以下版本重启后备机实例会有较长时间catchup状态，该状态下会占用主实例所在磁盘IO资源，IO能力较差数据量较多的情况下部分业务会出现运行较慢的情况，无其他影响，若集群启动后无重要业务可跳过。本小节主要用以估算该状态持续时间作为参考。步骤1 以omm用户登录GaussDB A集群的第一个CN节点步骤2 执行以下命令，启用环境变量source ${BIGDATA_HOME}/mppdb/.mppdbgs_profile步骤3 确认目前无实例catchup若当前存在catchup会影响集群重启后catchup时间。gsql -d postgres -p 25308 -c "select * from pgxc_get_senders_catchup_time()"如下查询无结果，则无实例catchup，可继续后续步骤。nodename | lwpid | local_role | peer_role | state | sender | catchup_start | catchup_end----------+-------+------------+-----------+-------+--------+---------------+-------------(0 rows) 步骤3 查看单个主dn实例路径cm_ctl query –Cvd|grep 60011  10-185-179-67 6001 /srv/BigData/mppdb/data1/master1     P Primary Normal | 2  10-185-179-95 6002 /srv/BigData/mppdb/data1/slave1      S Standby Normal | 3  ASG003        3002 /srv/BigData/mppdb/data1/dummyslave1 R Secondary Normal步骤4 统计主实例文件数量无严重数据倾斜情况下各个dn数据量相差不大，因此统计一个dn数据即可以代表其他实例的数据量，此处以实例6001为例。ls -fR /srv/BigData/mppdb/data1/master1/base|wc -l步骤5 根据主实例文件数量预计catchup时间HDD盘raid组：主实例文件数/800 (s)SSD盘：主实例文件数/1600 (s)4.2停止集群步骤1 以omm用户登录GaussDB A集群的第一个正常的cn节点步骤2 执行以下命令，启用环境变量source ${BIGDATA_HOME}/mppdb/.mppdbgs_profile步骤3 执行以下命令3次，设置检查点，防止集群重新启动后主实例长时间redo引起集群启动较慢。gsql -p 25308 -d postgres -c "checkpoint"执行结果如下，则为正常CHECKPOINT步骤4 执行以下命令，停止集群cm_ctl stop -mi 执行结果如下：cm_ctl: stop cluster.cm_ctl: stop nodeid: 1cm_ctl: stop nodeid: 2cm_ctl: stop nodeid: 3............cm_ctl: stop cluster successfully.4.3集群维护工作本步骤需结合具体方案目的实施，待集群成功停止后，可以开始进行停集群维护操作，如更换磁盘，升级网卡，下电服务器等。4.4启动集群步骤1 以omm用户登录GaussDB A集群的第一个正常的cn节点步骤2 执行以下命令，启用环境变量source ${BIGDATA_HOME}/mppdb/.mppdbgs_profile步骤3 执行以下命令，启动集群cm_ctl start -t 600 执行结果如下：cm_ctl: checking cluster statuscm_ctl: check finished in 247 ms.cm_ctl: start cluster.cm_ctl: start nodeid: 1cm_ctl: start nodeid: 2cm_ctl: start nodeid: 3........................................cm_ctl: start cluster successfully.4.5检查集群状态是否正常步骤1 以omm用户登录GaussDB A集群的第一个CN节点步骤2 执行以下命令，启用环境变量source ${BIGDATA_HOME}/mppdb/.mppdbgs_profile步骤3 执行以下命令，确保集群状态正常cm_ctl query如下则为正常[   Cluster State   ]cluster_state  :  Normalredistributing : Nobalanced       : Yes步骤4 确认集群状态是否正常。如果发生主备切换，则需要切回主备（具体参考主备切换标准方案）

1.    适用场景集群在运行过程中，出于运维目的数据库管理员可能需要手工对DN或GTM做主备切换。例如发现DN或GTM主备自动failover后想恢复原有的主备角色。2.    前提条件1) GaussDB A集群安装成功，且处于主备不均衡状态。2) 操作时间取得客户同意，并且确认为业务低峰期3.    对系统影响由于过程中会短暂实例服务不可用，故需要选择业务低峰期进行操作，从而减少因数据库主备切换对客户业务的影响。4.    变更步骤4.1检查集群状态处于不均衡状态步骤1 以omm用户登录GaussDB A集群的第一个正常的cn节点步骤2 执行以下命令，启用环境变量source ${BIGDATA_HOME}/mppdb/.mppdbgs_profile步骤3 执行以下命令，查看GaussDB A集群当前状态cm_ctl query 结果如下，balanced显示为No，则说明需要进行主备均衡，否则不需要执行此方案[   Cluster State   ] cluster_state  :  Normalredistributing : Nobalanced       : No4.2检查当前为业务低峰期若存在大量业务进行切换时会导致主实例等待业务进程退出长时间无法将备，集群持续不可用，因此执行均衡操作前需要确保处于业务低峰期。步骤1 以omm用户登录GaussDB A集群的第一个正常的cn节点步骤2 执行以下命令，启用环境变量source ${BIGDATA_HOME}/mppdb/.mppdbgs_profile步骤3 执行以下命令，查看当前业务情况gsql -d postgres -p 25308 -c " select * from pgxc_stat_activity where usename!='omm' and state='active'; "如下查询无结果或少于20条记录，则为正常，若大于20条记录联系客户停止当前运行业务或另找业务低峰期进行。coorname | datname | usename | pid | application_name | client_addr | backend_start | xact_start | query_start | state_change | waiting | enqueue | state | query_id | query----------+---------+---------+-----+------------------+-------------+---------------+------------+-------------+--------------+---------+---------+-------+----------+-------(0 rows) 4.3查看是否有主备追赶步骤1 以omm用户登录GaussDB A集群的第一个正常的cn节点步骤2 执行以下命令，启用环境变量source ${BIGDATA_HOME}/mppdb/.mppdbgs_profile步骤3 执行以下命令，确保Catchup视图无主备追赶gsql -d postgres -p 25308 -c "select * from pgxc_get_senders_catchup_time()"如下查询无结果，则为正常nodename | lwpid | local_role | peer_role | state | sender | catchup_start | catchup_end----------+-------+------------+-----------+-------+--------+---------------+-------------(0 rows)如果查询有结果，且结果持续没有变化，并且确认为业务低峰期，则联系华为工程师处理。4.4检查不均衡备DN redo进度 备机需要redo追齐主机才能升主成功，若备机redo进度与当前主实例相差较大执行均衡命令后，需要等备机redo完才能正式成为主机接管业务，在此之前集群持续不可用，因此在切换必须保证主备相差不大，缩短均衡时间。步骤1 以omm用户登录GaussDB A集群的第一个正常的cn节点步骤2 执行以下命令，启用环境变量source ${BIGDATA_HOME}/mppdb/.mppdbgs_profile步骤3 执行以下命令，查找不均衡DN实例cm_ctl query -Csdipv结果如下，6001和6002实例发生了主备切换[  Datanode State   ] node     node_ip         instance        state            | node     node_ip         instance        state            ----------------------------------------------------------------------------------------------------------------------1  host1 192.168.0.1  6001 25330      P Standby Normal | 2  host2 192.168.0.2  6002 25490      S Primary Normal当前的主（Primary）实例为6002,6002所在节点为host2，25490为6002进程的端口号步骤 4 登录第一个cn节点创建redo查询视图source ${BIGDATA_HOME}/mppdb/.mppdbgs_profilegsql -d postgres -p 25308 -r 连接到CN执行如下命令创建redo查询视图：CREATE OR REPLACE FUNCTION public.get_redo_info(OUT node_name name, OUT sender_replay_location text, OUT sender_flush_location text, out redoing bool)RETURNS SETOF RECORDLANGUAGE plpgsqlAS $$DECLAREV_SQL text;query_str text;rec record;result record;a text;b text;c text;d text;BEGINV_SQL := 'select node_name from pgxc_node where node_type = ''D'' and hostis_primary = ''f''';FOR rec IN EXECUTE(V_SQL) LOOPquery_str := 'EXECUTE DIRECT ON(' || rec.node_name || ') ''select sender_replay_location,sender_flush_location,receiver_replay_location,receiver_flush_location from pg_stat_get_wal_senders() where peer_role = ''''Standby'''' ''';EXECUTE query_str into result;node_name := rec.node_name;sender_replay_location := result.receiver_replay_location;sender_flush_location := result.receiver_flush_location;a := split_part(sender_replay_location, '/', 1);b := split_part(sender_flush_location, '/', 1);c := split_part(sender_replay_location, '/', 2);d := split_part(sender_flush_location, '/', 2);IF a = b THENredoing = 'f';ELSEredoing = 't';END IF;RETURN NEXT;END LOOP;RETURN;END$$;步骤 5  登录第一个cn节点查询redo进度source ${BIGDATA_HOME}/mppdb/.mppdbgs_profilegsql -d postgres -p 25308 -c " select * from get_redo_info(); "结果如下，0/1188D4B8为16进制数字，所有实例查询结果redoing项为f即为正常。  node_name   | sender_replay_location | sender_flush_location | redoing--------------+------------------------+-----------------------+--------- dn_6001_6002 | 0/1188D4B8             | 0/1188D4B8            | f(1 row)4.5连接CN执行checkpoint 步骤1 以omm用户登录GaussDB A集群的第一个正常的cn节点步骤2 执行以下命令，启用环境变量source ${BIGDATA_HOME}/mppdb/.mppdbgs_profile步骤3 执行以下命令，做checkpointgsql -d postgres -p 25308 -c "checkpoint"执行结果如下CHECKPOINT若超过5分钟未结束，则联系华为工程师处理。4.6检查当前集群是否有备份任务该步骤只需要在8.1.1(2021年330之后版本)以上版本进行判断，其余版本非均衡情况下不支持备份任务。若当前集群存在备份任务，进行集群均衡会导致备份失败。步骤1 以omm用户登录GaussDB A集群的第一个正常的cn节点步骤2 执行以下命令判断是否存在备份任务ps -ef|grep gs_roach|grep -v grep若输出为空则无备份任务，集群进行均衡操作，否则与客户沟通后停止备份集再进行均衡操作。步骤3 执行以下命令，停止备份任务python $GPHOME/script/GaussRoach.py -t stop -F4.7执行主备均衡步骤1 以omm用户登录GaussDB A集群的第一个cn节点步骤2 执行以下命令，启用环境变量source ${BIGDATA_HOME}/mppdb/.mppdbgs_profile步骤3 使用如下命令进行主备均衡cm_ctl switchover -a结果如下，则为正常cm_ctl: cmserver is rebalancing the cluster automatically.....cm_ctl: switchover successfully.4.8均衡操作是否成功1)后台集群状态验证步骤1 以omm用户登录GaussDB A集群的第一个正常的cn节点步骤2 执行以下命令，启用环境变量source ${BIGDATA_HOME}/mppdb/.mppdbgs_profile步骤3 执行以下命令，查看GaussDB A集群当前状态cm_ctl query如下则为正常[   Cluster State   ] cluster_state  :  Normalredistributing : Nobalanced       : Yes2)客户业务验证验证方案需包括DDL和DML语句

1.    适用场景当主机发生故障状态异常时，用户可能需要停止主机上的所有角色，对主机进行维护检查。故障清除后，启动主机上的所有角色恢复主机业务。2.    前提条件GaussDB A集群安装成功，且处于已启动状态。3.    对系统影响停止集群前需要用户先停止数据库相关业务，从而避免因数据库停止对客户业务的影响。4.    实施步骤4.1预估重启后实例catchup时间8.0以下版本重启后备机实例会有较长时间catchup状态，该状态下会占用主实例所在磁盘IO资源，IO能力较差数据量较多的情况下部分业务会出现运行较慢的情况，无其他影响，若集群启动后无重要业务可跳过。本小节主要用以估算该状态持续时间作为参考。步骤1 以omm用户登录GaussDB A集群的第一个CN节点步骤2 执行以下命令，启用环境变量source ${BIGDATA_HOME}/mppdb/.mppdbgs_profile步骤3 确认目前无实例catchup若当前存在catchup会影响集群重启后catchup时间。gsql -d postgres -p 25308 -c "select * from pgxc_get_senders_catchup_time()"如下查询无结果，则无实例catchup，可继续后续步骤。nodename | lwpid | local_role | peer_role | state | sender | catchup_start | catchup_end----------+-------+------------+-----------+-------+--------+---------------+-------------(0 rows) 步骤3 查看单个主dn实例路径cm_ctl query –Cvd|grep 60011  10-185-179-67 6001 /srv/BigData/mppdb/data1/master1     P Primary Normal | 2  10-185-179-95 6002 /srv/BigData/mppdb/data1/slave1      S Standby Normal | 3  ASG003        3002 /srv/BigData/mppdb/data1/dummyslave1 R Secondary Normal步骤4 统计主实例文件数量无严重数据倾斜情况下各个dn数据量相差不大，因此统计一个dn数据即可以代表其他实例的数据量，此处以实例6001为例。ls -fR /srv/BigData/mppdb/data1/master1/base|wc -l步骤5 根据主实例文件数量预计catchup时间HDD盘raid组：主实例文件数/800 (s)SSD盘：主实例文件数/1600 (s)4.2停止集群步骤1 以omm用户登录GaussDB A集群的第一个正常的cn节点步骤2 执行以下命令，启用环境变量source ${BIGDATA_HOME}/mppdb/.mppdbgs_profile步骤3 执行以下命令3次，设置检查点，防止集群重新启动后主实例长时间redo引起集群启动较慢。gsql -p 25308 -d postgres -c "checkpoint"执行结果如下，则为正常CHECKPOINT步骤4 执行以下命令，停止集群cm_ctl stop -mi 执行结果如下：cm_ctl: stop cluster.cm_ctl: stop nodeid: 1cm_ctl: stop nodeid: 2cm_ctl: stop nodeid: 3............cm_ctl: stop cluster successfully.4.3集群维护工作本步骤需结合具体方案目的实施，待集群成功停止后，可以开始进行停集群维护操作，如更换磁盘，升级网卡，下电服务器等。4.4启动集群步骤1 以omm用户登录GaussDB A集群的第一个正常的cn节点步骤2 执行以下命令，启用环境变量source ${BIGDATA_HOME}/mppdb/.mppdbgs_profile步骤3 执行以下命令，启动集群cm_ctl start -t 600 执行结果如下：cm_ctl: checking cluster statuscm_ctl: check finished in 247 ms.cm_ctl: start cluster.cm_ctl: start nodeid: 1cm_ctl: start nodeid: 2cm_ctl: start nodeid: 3........................................cm_ctl: start cluster successfully.4.5检查集群状态是否正常步骤1 以omm用户登录GaussDB A集群的第一个CN节点步骤2 执行以下命令，启用环境变量source ${BIGDATA_HOME}/mppdb/.mppdbgs_profile步骤3 执行以下命令，确保集群状态正常cm_ctl query如下则为正常[   Cluster State   ]cluster_state  :  Normalredistributing : Nobalanced       : Yes步骤4 确认集群状态是否正常。如果发生主备切换，则需要切回主备（具体参考主备切换标准方案）