通用方案:专有云V2环境AnalyticDB集群的上电方法

通用方案:专有云V2环境AnalyticDB集群的上电方法

更新时间:2020-06-24 18:14:57

1. 概述

本文主要介绍在专有云V2环境,发生集群断电后,如何启动AnalyticDB集群,恢复业务。

1.1. 适用范围

  • 专有云V2,AnalyticDB

1.2. 风险说明

进行业务恢复,风险低。

2. 问题描述

在专有云V2环境,由于生产环境的变动、业务需要或电力系统等故障,集群发生断电情况。发生集群断电后,需要启动AnalyticDB集群,恢复业务。

3. 解决方案

3.1. 环境检查

检查机器能否正常启动

对集群所有机器进行上电,如有机器无法正常启动,待集群恢复正常后,按规范流程将机器添加到黑名单进行维修。

在天目控制台上检查AnalyticDB集群是否到达终态

登录天目控制台,确认apsara_service--ads-XXXX集群和ads_service--ads-XXXX集群正常。如有异常,请先进行修复。

确认Garuda console和RMUI控制台可以正常登录

  1. 访问以下链接,登录Garuda Console,确认可以正常登录。
    http://[$Ads_AG_IP]:8080/console-dev
    说明:[$Ads_AG_IP]为ads_ag容器的IP,可登录CMDB控制台或天目控制台获取。
  2. 访问以下链接,登录RMUI控制台,确认可以正常登录。
    http://[$Gallardo_AG]:8315/index
    说明:[$Gallardo_AG]为gallardo_ag容器的IP,可登录CMDB控制台或天目控制台获取。

3.2. 实施步骤

打开迁移开关

登录Garuda Console,选择配置管理>高级>global>config>resourcemanager,将instanceShiftWorkerDisabled配置项的值改为false

说明true是关,false是开。

查看物理机中飞天服务是否正常启动

  1. 登录ads_ag容器,关于如何登录ads_ag容器,请参见专有云V2环境中如何登录容器
  2. 切换到admin用户,依次执行以下命令,确定返回结果都是SUCCESS,则表示正常。
    /home/admin/dayu/bin/allapsara status
    /home/admin/dayu/bin/allapsara start
    r ttrl |grep diskResource |awk '{print $1}' > tubo.list
    pssh -h tubo.lish -i "/home/admin/dayu/bin/apsarad status"

    如果没有启动,则需要登录到物理机,依次执行以下命令,启动飞天服务。

    /home/admin/dayu/bin/apsarad start
    /home/admin/dayu/bin/apsarad status

检查pangu是否有数据丢失

  1. 登录集群AG,执行以下命令,查看none级别的abnchunk。
    /apsara/deploy/puadmin fs -abnchunk -t none
    系统显示类似如下,确保返回结果为空。
  2. 执行以下命令,查看onecopy级别的abnchunk。
    /apsara/deploy/puadmin fs -abnchunk -t onecopy
    系统显示类似如下,确保返回结果为空。
  3. 执行以下命令,查看lessmin级别的abnchunk。
    puadmin fs -abnchunk -t lessmin
    系统显示类似如下,确保返回结果为空。
  4. 执行以下命令,检查机器pangu状态。
    puadmin lscs | grep tcp
    系统显示类似如下,确保机器状态都是NORMAL。
  5. 执行以下命令,确保AnalyticDB集群的机器数量正确。
    r ttrl
    系统显示类似如下。

检查节点进程是否启动正常

  1. 执行以下命令,检查节点进程是否启动正常。
    pssh -h tubo.list -i "jps | grep NodeMoniTor"
    系统显示类似如下。
  2. 如果存在机器没有启动NodeMoniTor进程,则登录ads_ag容器,切换到admin用户,执行以下命令,确认机器是否被fuxi管控。没有输出结果,表示没有被fuxi管控,则需要检查tubo服务是否正常,并联系阿里云技术支持。

    r ttrl |grep [$Hostname]
    说明:[$Hostname]为没有nodemonitor进程的主机名。

确认ads_meta库连接任务正常

登录ads_ag容器,切换到admin用户,登录ads_meta数据库,执行以下SQL语句。

mysql -h${ads_meta_host} -P${ads_meta_port} -u${ads_meta_user} -p${ads_meta_password} -D${ads_meta_name} -e "select state,count(*) from current_job group by state; "

系统显示类似如下。

确认每个库的节点数正常

  1. 登录ads_ag容器,切换到admin用户,执行以下命令,获取ads_meta数据库的连接信息。
    env | grep ads_meta
  2. 登录ads_meta数据库,执行以下SQL语句,查看库的节点数。
    select * from resource_request where table_schema='[$Table]' order by create_time desc limit 1\G
    说明:[$Table]为库名。
  3. 确认与DMS上查询的库的节点个数一致。
  4. 比对RMUI和Garuda Console上每个数据库节点数量,确保Garuda Console上没有缺少节点。

查看数据恢复情况

如果以上检查都符合预期,则观察sysdb数据库中数据加载情况。

  1. 登录ads_ag容器,切换到admin用户,依次执行以下命令,进入sysdb数据库。
    sysdb="sysdb."${ads_dns_subzone}"."${ads_dns_zone}
    mysql -h${sysdb} -P10000 -u${ads_account_accessId} -p${ads_account_accessKey} -Dsysdb -c -A
  2. 执行如下SQL语句,待PARTITION_STATUS全部变为FINISHED,代表数据加载完成,即可查询测试是否正常。
    select PARTITION_STATUS, count(*) from information_schema.localnode_task_status group by PARTITION_STATUS;
    系统显示类似如下。

检查数据导入任务

  1. 登录ads_meta数据库,执行以下SQL语句,确认task_state状态为SUCCEEDED,并且create_time是最近时间点。
    select table_schema,table_name, task_type ,task_state,create_time from build_current_task where table_schema= "[$DB_Name]" order by create_time desc limit 20;  
    说明:[$DB_Name]为实际数据库名。
  2. 执行以下SQL语句,确认task_state状态为SUCCEEDED,并且create_time是最近时间点。
    select table_schema,table_name, state,create_time,update_time 
    from table_data_request
    where table_schema= "[$DB_Name]" order by create_time desc limit 20;

3.3. 结果验证

  1. 在DMS控制台中,查询任意一个表,确认返回数据符合预期,无报错。
  2. 确认进行实时数据的录入无问题,可以进行查询。
  3. 确认数据同步任务可以进行,无异常。
  4. 登录ads_meta数据库,执行以下SQL语句,查看AnalyticDB的同步任务,无大量的失败failed任务。
    select task_type,task_state,count(*) from current_task group by task_state;
    系统显示类似如下。
    {21D875AD-C5FF-4DD8-8918-E8C168E193F3}_20200305152720.png 

4. 回滚方案

业务恢复,无需回滚。