1. CDM作业超时--总结常见的超时现象和处理方法1）参数配置配置连接，高级属性5分钟超时报错连接属性配置2）truncate等锁超时     https://blog.csdn.net/turbo_zone/article/details/84036511CDM作业入库的时候报了违反唯一约束truncate掉，重新抽取3）后台压力    后台压力报错杀掉执行时间很长且占用io的sql4）hive侧配置MetaStore的内存配置的小，后台不断在FullGCHive: MetaStore 调整前：-Xms1024M -Xmx4069M -XX:NewSize=512M -XX:MaxNewSize=609M调整后：-Xms4096M -Xmx8192M -XX:NewSize=2048M -XX:MaxNewSize=2048M2. 磁盘空间使用率高，定位到大表--总结整理处理方法--数据倾斜1）查看磁盘使用率超过90%   pg_namespace    pg_class  pg_database84%2）sql语句查看全表倾斜SELECT * FROM pgxc_get_table_skewness Where totalsize > 100*1024*1024 and skewratio > 0.05 ORDER BY totalsize DESC;  SELECT * FROM pgxc_get_table_skewness ORDER BY totalsize DESC3）查看单表倾斜--方法一：用管理员用户连接集群，执行以下SQL语句：select table_skewness('schemaname.tablename');--方法二：用管理员用户连接集群，执行以下SQL语句：select table_distribution('schemaname','tablename');                ？ SELECT a.count,b.node_name FROM (SELECT count(*) AS count,xc_node_id FROM table_name GROUP BY xc_node_id) a, pgxc_node b WHERE a.xc_node_id=b.node_id ORDER BY a.count desc;导入新表3. 主备切换--定位主备切换的原因和应急方法     故障 cm_ctl start -n 2 -D  /srv/BigData/mppdb/data2/master2 cm_ctl stop -n 2 -D  /srv/BigData/mppdb/data2/master2   故障恢复 cm_ctl start -n 2 -D  /srv/BigData/mppdb/data2/master2    故障top   看时间2020-11-08 02:38:52 看主备倒换时间4. DWS页面odbc/jdbc驱动无法下载--如何正确配置hosts？--其他情况5. 账户被锁--应急方法https://support.huaweicloud.com/trouble-dws/dws_09_0030.html--被锁的原因：查看审计日志select * from pg_query_audit('2020-11-17 8:00:00','2020-11-17 10:00:00') where type ='login_failed';6. 审计日志DWS页面上设置：https://support.huaweicloud.com/mgtg-dws/dws_01_0075.htmlhttps://support.huaweicloud.com/mgtg-dws/dws_01_0142.html--pgxc_query_audit  ：查看所有CN节点审计日志。--开关audit_enabled（总开关）audit_system_object（默认12295，不审计表，12303可以审计表）audit_resource_policy（on表示空间优先，国网cn日志目录太小，建议空间优先）audit_space_limit  一般1g  

【功能模块】【操作步骤&问题现象】想问下，发生主备切换后，原来的主成为备，显示need repair(disconnected), 整个集群是unavailable的状态，这种情况下，标准的处理步骤是怎么样的？是需要杀死cm_server进程让其重启并重新仲裁主备关系么？【截图信息】【日志信息】（可选，上传日志内容或者附件）

主备同步，也叫主从复制，是MySQL提供的一种高可用的解决方案，保证主备数据一致性的解决方案。在生产环境中，会有很多不可控因素，例如数据库服务挂了。为了保证应用的高可用，数据库也必须要是高可用的。因此在生产环境中，都会采用主备同步。在应用的规模不大的情况下，一般会采用一主一备。除了上面提到的数据库服务挂了，能够快速切换到备库，避免应用的不可用外，采用主备同步还有以下好处：提升数据库的读并发性，大多数应用都是读比写要多，采用主备同步方案，当使用规模越来越大的时候，可以扩展备库来提升读能力。备份，主备同步可以得到一份实时的完整的备份数据库。快速恢复，当主库出错了（比如误删表），通过备库来快速恢复数据。对于规模很大的应用，对于数据恢复速度的容忍性很低的情况，通过配置一台与主库的数据快照相隔半小时的备库，当主库误删表，就可以通过备库和binlog来快速恢复，最多等待半小时。说了主备同步是什么和好处，下面让我们来了解一下主备同步是怎么实现的。主备同步的实现原理下面以一个update语句来介绍主库与备库间是如何进行同步的。上图是一个update语句在节点A执行，然后同步到节点B的完整流程图，具体步骤有：主库接受到客户端发送的一条update语句，执行内部事务逻辑，同时写binlog。备库通过 change master 命令，设置主库的IP、端口、用户名和密码，以及要从哪个位置开始请求 binlog。这个位置包含文件名和偏移量。在备库上执行start slave命令，启动两个线程 io_thread 和 sql_thread，其中 io_thread 负责与主机进行连接。主库校验完用户名和密码，按照接收到的位置去读取binlog，发给备库。备库接收到binlog后，写到本地文件（relay log，中转文件）。备库读取中转文件，解析出命令，然后执行。主备同步的工作原理其实就是一个完全备份加上二进制日志备份的还原。不同的是这个二进制日志的还原操作基本上是实时的。备库通过两个线程来实现同步：一个是 I/O 线程，负责读取主库的二进制日志，并将其保存为中继日志。一个是 SQL 线程，负责执行中继日志。从上面的流程可以看出，主备同步的关键是binlog常见的俩种主备切换流程MS结构M-S结构，两个节点，一个当主库、一个当备库，不允许两个节点互换角色。对比前面的M-S结构图，可以发现，双M结构和M-S结构，其实区别只是多了一条线，即节点A和B之间总是互为主备关系。这样在切换的时候就不用再修改主备关系。双M结构的循环赋值问题在实际生产使用中，多数情况是使用双M结构的。但是，双M结构还有一个问题需要解决。业务逻辑在节点A执行更新，会生成binlog并同步到节点B。节点B同步完成后，也会生成binlog。（log_slave_updates设置为on，表示备库也会生成binlog）。当节点A同时也是节点B的备库时，节点B的binlog也会发送给节点A，造成循环复制。解决办法：设置节点的server-id，必须不同，不然不允许设置为主备结构备库在接到binlog后重放时，会记录原记录相同的server-id，即谁产生即为谁的。每个节点在接受binlog时，会判断server-id，如果是自己的就丢掉。解决后的流程：业务逻辑在节点A执行更新，会生成带有节点A的server-id的binlog。节点B接受到节点A发过来的binlog，并执行完成后，会生成带有节点A的server-id的binlog。节点A接受到binlog后，发现是自己的，就丢掉。死循环就在这里断掉了。

【功能模块】【操作步骤&问题现象】比如通过gs_om -t status --detail发现有些实例发生了主备切换，想了解下是什么情况下会发生主备切换，后台是一个什么检测逻辑，能否详细解释下【截图信息】【日志信息】（可选，上传日志内容或者附件）

【功能模块】想咨询下什么情况会导致主备不同步【操作步骤&问题现象】当前使用GAUSS导入数据以下两种方式1.一种是COPY2.一种是GDS当导入数据量上亿条时集群界面就会出现主备不同步告警，且集群运行其他SQL就开始卡顿集群规模12台机器，内存512，每台机器数据盘做了4组raid

请教一下cloudtable服务集群有没有支持容灾备份，如果支持，请详细说明一下，谢谢！

当升级前巡检发现sequence在CN和GTM上不一致时，使用下文进行修复名称介绍(以下名称将在下文使用)：N1： 第一个cn实例所在的节点G1：GTM主实例所在的节点prefixPath: 修复sequence所创建的一个临时目录，此数据库用户必须有对此目录的访问权限--执行以下文档时将N1和prefixPath替换为真实的路径1. 在N1节点创建此目录，并且进入到此目录mkdir prefixPath2. 获取所有数据库列表 gsql -p 25308 postgres -r -t -c "select datname from pg_database where datname not in ('template1', 'template0', 'template2', 'information_schema');" > datname.txt 3. 生成所有sequence名字cat datname.txt | while read LINE       doif [ -z "$LINE" ]; thenecho "skip"elsegsql -p 25308 $LINE -r -t  -c "SELECT current_database()||'.'|| ns.nspname||'.'|| c.relname|| '\00' FROM pg_catalog.pg_namespace ns, pg_catalog.pg_class c WHERE c.relnamespace = ns.oid and c.relkind = 'S' ORDER BY c.oid;" >seq_name.$LINEfi     done4 合并所有数据库的seqrm seq_name.allcat datname.txt | while read LINE       doif [ -z "$LINE" ]; thenecho "skip"elsecat seq_name.$LINE >> seq_name.allfi     done5. 整理seq_name.all 删除空行sed  -i '/^$/d' seq_name.all删除每行第一个空格sed -i 's/^ //g' seq_name.all6. 停止数据库集群的gtm主备实例(主备两个节点，若停不掉时kill，然后在stop，其中-n 后面指的是cm_ctl query -Cvd查出来的实例所在节点的编号)cm_ctl stop -n "" -D gtmpath_standbycm_ctl stop -n "" -D gtmpath_primary7. 在G1(GTM主)上获取sequence(cm_ctl query -Cvd | grep gtm 命令查看gtm的数据目录,默认一般路径在/opt/huawei/Bigdata/mppdb/gtm)，然后将seq_gtm.txt以及gtm.head copy到N1的 prefixPath 目录sed -n '4,$p' (/opt/huawei/Bigdata/mppdb/gtm[此路径替换为真实路径])/gtm.control > seq_gtm.txthead -n 3 (/opt/huawei/Bigdata/mppdb/gtm[此路径替换为真实路径])/gtm.control > gtm.head8. 启动gtm主备cm_ctl start-n "" -D gtmpath_primarycm_ctl start -n "" -D gtmpath_standby9. 创建所需要的临时表(以下在使用gsql在postgres库执行)drop schema seq_schema_upgrade;create schema seq_schema_upgrade;drop table if exists seq_schema_upgrade.seq_store;create table seq_schema_upgrade.seq_store(seq_name text not null, cur_val text default '200000', start_value text default '1',increment_by text default '1',  min_value text default '1',  max_value text default '9223372036854775806',is_cycled_str text default 'f', is_called_str text default 'f', active text default '1');--store sequence from gtm_control file create table seq_schema_upgrade.seq_gtm(seq_name text not null, cur_val text default '200000', start_value text default '1',increment_by text default '1',  min_value text default '1',  max_value text default '9223372036854775806',is_cycled_str text default 'f', is_called_str text default 'f', active text default '1');--store sequence from coordinatorcreate table seq_schema_upgrade.seq_cn(seq_name text not null, cur_val text default '200000', start_value text default '1',increment_by text default '1',  min_value text default '1',  max_value text default '9223372036854775806',is_cycled_str text default 'f', is_called_str text default 'f', active text default '1');10. 分别将gtm.control和cn上的sequence导入到seq_schema_upgrade.seq_gtm和seq_schema_upgrade.seq_cn表(以下在使用gsql在postgres库执行)copy seq_schema_upgrade.seq_cn(seq_name) from 'prefixPath/seq_name.all' with (format 'csv', delimiter E'\t');copy seq_schema_upgrade.seq_gtm from 'prefixPath/seq_gtm.txt' with (format 'csv', delimiter E'\t');--注意：seq_schema_upgrade.seq_gtm中若有乱码sequence导致copy失败，则需要在seq_gtm.txt文件删掉乱码行，再行导入11. 在数据库中生成所有最新的sequence(以下在使用gsql在postgres库执行)，check insert into seq_schema_upgrade.seq_store select gtm.* from seq_schema_upgrade.seq_gtm gtm, seq_schema_upgrade.seq_cn cn where gtm.seq_name = cn.seq_name;insert into seq_schema_upgrade.seq_store select cn.seq_name from seq_schema_upgrade.seq_cn cn where not exists (select seq_name from seq_schema_upgrade.seq_gtm gtm where cn.seq_name = gtm.seq_name);select count(cn.seq_name) from seq_schema_upgrade.seq_cn cn;select count(seq_store) from  seq_schema_upgrade.seq_store;--注意：此处需要检查 两个count总数是否相等copy seq_schema_upgrade.seq_store to 'prefixPath/seq_total.csv' with (format 'csv', delimiter E'\t');drop schema seq_schema_upgrade cascade;12. 生成最终的gtm.control信息(在N1节点的 prefixPath 下执行)head -n 3 gtm.head > gtm.controlcat seq_total.csv >> gtm.control13.停止数据库集群的gtm主备实例(主备两个节点，若停不掉时kill，然后在stop)cm_ctl stop -n "" -D gtmpath_standbycm_ctl stop -n "" -D gtmpath_primary14. 将生成的gtm.control文件copy到GTM的主备的各个实例路径下15. 启动gtm主备cm_ctl start -n "" -D gtmpath_primarycm_ctl start -n "" -D gtmpath_standby升级后若出现sequence值重复可以以下方法修复：1. 在对应的数据库上创建find_noe_seq函数2. 使用这个函数查询当前sequence最大值，输出的第二列值就是当前最大值3. select sequence_name,uuid  from seqName;4. 停止数据库的gtm主备5. 在gtm目录的gtm.sequence文件中根据uuid找到匹配的行，替换第二个字段，注意不要引入误将tab替换为空格，主备都要替换6. 启动数据库GTM主备实例--find_one_seq函数定义如下：create or replace procedure find_one_seq(dbname text, schmaname text, seq_name text)astablename   varchar(1000);columnname  varchar(1000);schemanname varchar(1000);        rel_oid     Oid;        adnum       int;cur_max_seq int;max_seq     int;start_value bigint;increment_by bigint;max_value bigint;min_value bigint;cache_value bigint;is_cycled  bool;is_cycled_str char(1);is_called  bool;is_called_str char(1);        type ref_cur_type is ref cursor;        my_cur ref_cur_type;              my_cur_seq_name ref_cur_type;        my_cur_rel_att_name ref_cur_type;        my_cur_max_seq_num ref_cur_type;my_seq_info ref_cur_type;        sqlstr varchar(1000);sqlstr2 varchar(2560);sqlstr3 varchar(2560);sqlstr4 varchar(2560);begin        max_seq = 1;        sqlstr='select adrelid, adnum from pg_attrdef where adsrc like ''%' || seq_name || '%''';        open my_cur_seq_name for sqlstr;        fetch my_cur_seq_name into rel_oid, adnum;        while my_cur_seq_name%found loop            -- dbms_output.put_line('-> ('||rel_oid || ' , ' || adnum || ')');            cur_max_seq = 0;sqlstr2  = 'select c.relname as tablename, a.attname, n.nspname as columname from pg_class c, pg_attribute a, pg_namespace n where c.relnamespace = n.oid and c.oid = a.attrelid and a.attrelid = ' || rel_oid || ' and a.attnum = ' || adnum || ';';open my_cur_rel_att_name for sqlstr2;fetch my_cur_rel_att_name into tablename, columnname, schemanname;while my_cur_rel_att_name%found loop--     dbms_output.put_line('-> ('|| tablename || ' , ' || columnname || ')');sqlstr3 = 'select max(' || columnname || ') from ' || schemanname || '.' ||tablename || ';';open my_cur_max_seq_num for sqlstr3;fetch my_cur_max_seq_num into cur_max_seq;    if (cur_max_seq > max_seq) then       max_seq = cur_max_seq;    end if;close my_cur_max_seq_num;     fetch my_cur_rel_att_name into tablename, columnname;end loop;close my_cur_rel_att_name;            fetch my_cur_seq_name into rel_oid, adnum;        end loop;        close my_cur_seq_name;-- dbms_output.put_line(seq_name || ' max value : ' || max_seq);sqlstr4 = 'select start_value, increment_by, max_value, min_value, cache_value, is_cycled, is_called from ' || schmaname || '.' || seq_name;open my_seq_info for sqlstr4;fetch my_seq_info into start_value, increment_by, max_value, min_value, cache_value, is_cycled, is_called;while my_seq_info%found loop if (is_cycled) thenis_cycled_str = 't';elseis_cycled_str = 'f';end if;is_called_str = 't';max_seq = max_seq + 20000;    dbms_output.put_line(dbname || '.'|| schmaname || '.' ||seq_name || '\00' || E'\t' || max_seq || E'\t' || start_value || E'\t' || increment_by || E'\t' || min_value || E'\t'|| max_value || E'\t' || is_cycled_str || E'\t' || is_called_str || E'\t' || '1');fetch my_seq_info into start_value, increment_by, max_value, min_value, cache_value, is_cycled, is_called;   end loop;close my_seq_info;end;/

【问题描述】            该局点FusionCompute版本为6.5.1，VRM以虚拟机主备部署的方式部署。FusionCompute上产生主备VRM数据库同步异常的告警，并且登录页面闪退。【告警信息】             FusionCompute上产生“主备VRM数据库同步异常”和“心跳异常”的告警【处理过程】             1、使用“gandalf”账号登录主备VRM的后台，切换到“root”账户，执行命令查询VRM状态：service had query经查询，发现主备VRM状态都为“active”，说明出现双主状态。2、使用命令“reboot”重启备VRM，使其状态切换为“standby”状态，解决双主状态的问题。3、在上图中可发现主备VRM之间心跳链路丢失，无法检测到对方的存在，此时需要在备VRM上输入以下命令，添加心跳链路：sh /opt/galax/gms/common/ha/configHA.sh -m slave -l本端节点管理IP地址 -p对端节点管理IP地址 -L本端节点主机名称 -P对端节点主机名称 -f浮动IP地址 -M子网掩码 -g仲裁IP地址4、配置完心跳链路后，主备VRM完成心跳建立，但此时备VRM的状态为“NULL”，只需重启备VRM即可。5、重新登录FusionCompute页面，告警自动消除，并且页面不再出现闪退。【根因】             平台非正常下电引起，现场没有根据下电流程规范下电。转自：https://support.huawei.com/enterprise/zh/knowledge/EKB1100048494?idAbsPath=22658044%7C7919788%7C9856606%7C21462752%7C8576912

pgxc_node这个系统表，在每个cn都有自己的一个表，用来帮助cm去仲裁整个集群的状态，其中，每一组dn实例会在其中有一行数据，如下图：dn_6001_6002在这个表里是一行，其中hostis_primary这个字段，标识这当前6001是否是主dn，如果是t则是6001是主，如果是f，则是6002是主。在系统发生异常，由于HA机制，进行主备倒换的时候，会出现hostis_primary这个值变成f的情况。【问题描述】很小几率下会出现，hostis_primary值为f，但是集群中并没有主备倒换，都是正常的。这个情况有一定概率会出现，详细原因不做赘述，此时有两种解决办法。【解决方案】两种方法都不影响业务：手动update出问题的cn的pgxc_node。update table pgxc_node set hostis_primary = 't' where node_name like '%dn_6001_6002%';kill 一下问题节点的cmagent，可以自动刷新该系统表。

场景描述：在manager页面上，可以查到主备OMS节点的节点信息（实心星号和空心星号）；当OMS节点出现不可修复的故障，需要保障有一台主oms节点正常运行，卸载备节点，并重新安装；（参照产品文档，更换管理节点章节）在后台通过uninstall命令卸载oms后，发现manager页面仍然留有之前故障节点的主机信息；（当时未保存图片，以下图代替）问题影响：后端已经卸载，前端还有残留信息，前后端不一致，影响后续其他变更及维护工作解决方法：连接manager的数据库gsql -p port -U user -W password删除public.om_nodes表中错误的host记录（该步骤删除前先备份该表）    3.通过后台命令 sh ${BIGDATA_HOME}/om-server/om/sbin/stop-oms.sh关掉备OMS节点（先关备，防止主备倒换）    4.通过后台命令 sh ${BIGDATA_HOME}/om-server/om/sbin/restart-oms.sh重启主OMS节点，页面缓存清除    5.此时页面找不到残留的host信息，前后端一致

【背景】 SQLserver原生产品不支持主备之间作业自动同步，主备集群架构下备节点需手动配置作业，避免主节点故障或者降备，备节点升主后集群作业不生效。影响数据同步或者数据迁移。以下操作指导介绍如何在华为云上通过DAS登录备节点同步主节点作业。【试验环境】【环境配置】1.   通过以下SQL脚本，创建timedtask数据库、taskinfo表、初始化表数据--创建数据库CREATE DATABASE timedtask;--创建表USE [timedtask];CREATE TABLE [dbo].[taskinfo] (        [ID] int NOT NULL,        [taskname] varchar(50) NULL,        [begintime] datetime DEFAULT GETDATE() NULL,        [endtime] datetime DEFAULT GETDATE() NULL,        PRIMARY KEY CLUSTERED ([ID]));--插入数据insert into [taskinfo] ([ID],[taskname],[begintime],[endtime]) values ('1','taskinfo-table-back','2020-10-09 14:21:07.417','2020-10-09 14:21:07.417');insert into [taskinfo] ([ID],[taskname],[begintime],[endtime]) values ('2','taskinfo-table-back','2020-10-08 14:22:04.000','2020-10-08 14:22:04.000');insert into [taskinfo] ([ID],[taskname],[begintime],[endtime]) values ('3','taskinfo-table-back','2020-10-07 14:23:17.000','2020-10-07 14:23:17.000');insert into [taskinfo] ([ID],[taskname],[begintime],[endtime]) values ('4','taskinfo-table-back','2020-10-06 14:22:23.173','2020-10-06 14:22:23.173'); 2.  下载安装SQL Server Management Studio数据库客户端https://docs.microsoft.com/en-us/sql/ssms/download-sql-server-management-studio-ssms?view=sql-server-20173.   准备作业执行SQL脚本DECLARE @UNIXTIME varchar(255),        @TABLES_NAME varchar(255),        @str_sql nvarchar(MAX);SET @UNIXTIME =cast (DATEDIFF(SS,'1970-1-1 00:00:00',GETUTCDATE()) as varchar(255));SET @TABLES_NAME='taskinfo_bak_'+ @UNIXTIME;SET @str_sql='select * into ' + @TABLES_NAME  +  ' from taskinfo' ;EXEC sp_executesql @str_sql;【操作步骤】1.   使用SSMS客户端登录数据库（主节点）2.   创建作业“备份taskinfo表”，并每周日凌晨0点执行作业（主节点）。3.   将新建的作业“备份taskinfo表”导出为SQL脚本用于同步作业到备节点 ，右击鼠标选择编辑作业脚本为-CREATE到-新查询编辑器窗口，如下图所示。4.   登录备节点：使用DAS工具登录数据库，点击“SQL操作-SQL窗口”，点击“主库 切换SQL执行点”，如下图所示5.   确认登录到备库后，然后在SQL查询窗口执行，从“步骤三拷贝的SQL脚本”，并确认执行成功。注意：一般数据库作业都是大批量事务，建议在业务低峰期执行，避免在高峰期执行影响数据库的性能。

 对于数据库来说，可用性和可靠性是永恒的话题，DBA会按照业务的不同要求选择不同的策略保证系统正常运作，其中包含数据库本身内核提供的能力和外部的监控管理系统。商用数据库提供全套的管理系统，缺点只有一个，贵。开源数据库也有很多生态工具以及借助于其他组件的解决方案，也能完成相应功能，但有一定的技术门槛和维护成本。   云数据库服务以较低的价格提供了企业级的解决方案，并节省了运维成本，只需要配置，服务就能按照业务诉求执行不同的管理策略，是企业的高性价比选择。 而不同的云厂商提供的方案和策略也是不同的。首先从底层实现上，有两类，1是通过底层能力，比如AWS的DRBD方案，类似传统shared disk的冷备方案。 其他大部分厂商都利用数据库本身的能力即数据库主备同步的方式来实现。  MySQL有两种replication模式：  异步： 主机事务提交不会确认备机是否接到数据，写入和数据传输是个异步过程，主机性能比较好。  半同步：通常情况下主机会等待备机收到同步过去的binlog才提交数据，这样能保证数据不丢失。但是这个能否保证数据不丢失呢？ 答案是否定的，当网络异常或其他因素影响时，复制方式会降为异步。 所以半同步大体来说就是尽量保证数据不丢，但是在异常场景下还是可用性优先。华为RDS是怎么做的呢？  首先在客户可以选根据业务可以选择复制模式， 如果业务有对账系统，希望保证最大的可用性和性能可以选择异步； 如果对可靠性要求较高可以选择半同步。  另外还增加了HA策略选择，客户可以选择高可用模式和高可靠模式。 HA monitor除了对主备实例进行健康检查以外还记录主备的同步情况；在高可用模式下发现故障直接切换。高可靠模式是HA monitor会根据当前的主备延迟进行判断，达到一定阈值则进行可靠性保护，不进行切换，保证数据库的可靠性。有了这两种设置，客户可以充分的根据业务进行灵活选择。  除了HA处理外，华为云还提供了补偿机制，可以将HA丢失数据找回，支持事后对账。当主备切换原主恢复后，会与原备新主做数据检查，将丢失的部分数据生成一个“碎片备份”， 客户可以在备份列表中看到，然后根据业务需要选择将这部分数据进行恢复。  上面是华为在云服务化方面的优化处理，提供了强大的管理能力。 而在内核优化版本HWSQL上，更是结合内核和服务化进一步优化：进行了半同步模式性能优化、并行复制等优化，半同步模式下性能损耗大幅降低，加上其他方面的性能优化，在半同步模式下HWSQL也能提供业界领先的性能表现，自信屏蔽异步模式。  在HA策略上，提供探针和降异步接口，控制降异步的过程，根据客户的选择可以提供强同步模式，保证数据0丢失。 在此模式下，如果故障则不进行切换，但是对于故障不会置之不理，虚拟化层的可靠性策略可以进行虚拟机层的HA漂移，将原主恢复。从服务化到数据库内核到底层平台，华为RDS提供了360度的数据库SLA保障。

场景描述有时候客户会遇到RDS主备复制关系异常的情况，可能原因是误删除默认安全组策略，下面主要针对这个场景进行分析，供您参考。解决方案 步骤 1    登录管理控制台。 步骤 2     单击管理控制台左上角的  ，选择区域和项目。               您可选择自己的专属计算集群（DedicatedCoumputing Cluster ，简称DCC）创建实例。步骤 3     选择“数据库> 关系型数据库”。进入关系型数据库信息页面。步骤 4     在“实例管理”页面，选择指定的实例，单击实例名称。步骤 5     在“基本信息”页面，单击目标安全组名称，进入实例安全组页面。步骤 6     单击“添加规则”，选择入方向，Any协议，源地址为自身安全组，即安全组的远端要有安全组自己 。步骤 7   添加完策略之后准备复制的关系就恢复正常了。

【关 键 词】：主备HDC数据库异常，告警ID 1001005，无HDC服务器异常告警【使用版本】：FusionAccess【故障模式】：HDC数据库用户密码被修改【案例密级】：访客公开【问题现象】：FA上有主备HDC数据库异常告警，告警ID都为1001005，在系统配置上进行ITA配置无法成功，提示HDC连接数据库异常；【问题分析】：1、首先按FA告警提示解决步骤排除了IP、网络和数据库服务异常影响；2、  通过web访问hdc返回信息。在ITA服务器上通过service ha status 查看各组件状态，均显示正常；查看Gaussdb进程和端口情况，发现服务正常；切换至Gaussdb用户gaussdba，运行gs_ctl status ，返回错误； 3、  通过gsql –d portgres –W 密码 命令进入数据库，解锁账号hdcdbuser、ITALoginUser，重启ha服务后依旧存在告警；4、  通过命令检查Gaussdb用户默认密码是否被修改，发现hdcdbuser密码不是默认密码，进入数据库修改此用户密码为默认密码，告警正常清除。【问题根因】：通过上述步骤可以看到，该问题出现根因在于Gaussdb用户hdcdbuser密码被修改，未及时更新到FA配置导致。【问题建议】：在线网环境中一定要做好FA各组件的账号密码管理工作，如果修改需要及时进行更新说明，在FA上进行相关配置调整。 

数据库实例存储类型数据库系统通常是IT系统最为重要的系统，对存储IO性能要求高，您可根据需要选择您所需的存储类型。RDS暂时不支持创建实例后变更存储类型。表1 存储类型简介存储类型说明超高IO最大吞吐量为350MB/s。超高IO（尊享版）是一种兼具本地盘写入速度和云盘数据可靠性的创新存储类型，数据写入时将MySQL的日志写入本地盘，提升数据的写入速度，数据写入云盘，保证数据的可靠性。说明：超高I/O（尊享版）存储类型仅支持超高性能型（尊享版）规格的实例。混合SSD盘混合SSD为华为研发的创新SSD存储，使用本地盘+云盘混合存储方案，数据写入并存储在本地盘，当本地盘存储空间不足，数据可写入华为高速云盘，保证IO性能的同时，避免了实例跨机迁移带来的稳定性风险。数据库实例状态数据库实例状态数据库实例状态是数据库实例的运行情况。用户可以使用管理控制台和API操作查看数据库实例状态。表1 状态及说明状态说明正常数据库实例正常和可用。异常数据库实例不可用。创建中正在创建数据库实例或备份。创建失败数据库实例创建失败。主备切换中正在进行主实例和备实例的切换。转主备中单机实例正在转换为主备实例。重启中按照用户请求，或修改需要重启才能生效的参数后重启实例。端口修改中正在修改数据库实例的数据库端口。规格变更中数据库实例的CPU和内存规格变更中。扩容中数据库实例的磁盘空间扩容中。恢复中正在恢复备份到实例中。恢复失败实例恢复失败。冻结账户余额小于或等于0元，系统对该用户下的实例进行冻结。您需前往费用中心充值成功，欠款核销后，冻结保留期内的实例才会解冻。有关冻结和解冻，详情请参见冻结和解冻。存储空间满实例的磁盘空间已满，此时不可进行数据库写入操作，您需要扩容磁盘使实例恢复到正常状态。转包周期中按需付费实例正在转为包周期实例中。已删除数据库实例已被删除，对于已经删除的实例，将不会在实例列表中显示。实例小版本升级中实例正在升级中。版本升级实例版本正在升级中。备机迁移中MySQL备机正在迁移可用区中。参数模板状态参数模板状态是数据库参数修改后的应用及生效情况。用户可以使用管理控制台和API操作查看参数状态。表2 状态和说明状态说明同步数据库参数已生效。应用中数据库参数修改后，正在应用。等待重启数据库参数修改后，有些参数修改，需等待用户重启实例才能生效。