背景及现象
03月01接到客户要求，处理其MySQL问题，原本告知只是三节点的的主从同步异常，需要将数据库拉起来重新同步，想必是个简单的问题。
但show slave status三个节点后发现，并没有主从同步的信息，第二天前往现场和客户了解详细情况，并通过详细的检查发现，其1节点数据库从2021年12月1日已经出现未同步的情况，2节点从2022年2月23日出现异常，3个节点各自独立,可以正常启动,但无法建立集群关系和对外提供访问。
分析过程
2.1 登录各节点查看数据库信息
检查各节点数据库版本信息如下：
mysql Ver 14.14 Distrib 5.7.36, for Linux (x86_64) using EditLine wrapper2.2 检查各节点数据库状态如下，三个节点数据库均为启动状态：
2.3 检查数据库集群3个成员状态如下，目前集群中所有成员状态均为offline：
2.4 检查数据集群3个成员GTID情况，3节点数据为最新数据。
db03
db02
db01
2.5 检查集群router配置文件无误。
2.6 对比各节点大表数据量情况如下，2节点数据量最多，3节点其次，1节点最少。
2.7 检查数据库后台日志情况如下：
Db01：数据库一节点在2021-11-30日开始就存在磁盘空间不足导致应用的日志无法写入磁盘,同步出现异常。
Db02：数据库2节点从2022-02-12日开始就存在磁盘空间不足导致应用的日志无法写入磁盘,同步出现异常。
Db03：数据库3节点从2022-02-24日开始存在主从复制异常，无法连接到db01、db02节点。
综上情况分析：
该数据库集群属于一主两从的MySQL Router+Innodb Cluster集群, db03,db01为主,db02为从，但db01在2021年11月30日就已有问题，此节点已无效，需要重建。
主节点于2月24日无法连接其他两节点，且binglog日志已经被删除，最终由于异常宕机导致集群不可用，目前是3节点以单实例方式对业务提供写的需求。和客户讲述集群情况，最后确认两种方案同时进行：
尝试恢复现有集群，踢出1节点成员，3、2节点一主一从对外提供服务，不允许在现有集群中做备份任务(主机空间不足，且备份锁表影响业务);
新建一套集群，将客户自行备份的数据(近500G的SQL文件)恢复到新集群中。
处理过程
和客户沟通后，备份操作会影响已运行的主库，取消了该操作，直接开始对2节点做节点恢复工作，集群成员恢复至2个节点，但2节点因存储空间问题同步失败，无法成为正常工作节点。
Db02无法找到需要同步的日志文件。
3.2 针对节点无法加入集群的故障，使用重置节点的方案，将db01、db02踢出集群后重新加入集群，操作方案如下：
按照以上方案，在扩容db01节点存储空间后，执行集群添加节点操作报错如下：
MySQL5.7不支持clong节点的方法重置新节点，需要升级至8.0版本，随放弃方案1，直接开始方案2。
客户直接使用RPM安装了一套MySQL 8.0.28版本的集群后，直接开始将数据导入到新集群中，第二天查看日志，导入90G左右后异常终止了，排查日志发现集群的3节点自动重启了….
导入脚本只有如下一个错误（query aborted）：
怀疑是参数的问题，进过一系列的系统参数调优、数据库参数调优：
#核心参数建议
skip_name_resolve =ON
explicit_defaults_for_timestamp =ON
log_timestamps =SYSTEM
max_connections=1000
max_connect_errors = 10000000
max_heap_table_size = 2048M
tmp_table_size = 2048M
lower_case_table_names=0
#*************** gtid ***************
binlog_format = ROW
binlog_rows_query_log_events = ON
gtid_mode = ON
enforce_gtid_consistency = ON
log_slave_updates = ON
transaction_write_set_extraction = XXHASH64
###开启主键信息采集功能，8.0.2开始默认值为XXHASH64
binlog_checksum = NONE
innodb_write_io_threads = 8
innodb_read_io_threads = 8
innodb_flush_method = O_DIRECT
innodb_buffer_pool_size = 16G
innodb_buffer_pool_instances = 6
#数据导入性能参数建议：
set global group_replication_flow_control_mode=QUOTA ;
set global group_replication_flow_control_applier_threshold=150000; --控制复制流
set global group_replication_flow_control_certifier_threshold=150000;
set global max_allowed_packet=536870912; --控制最大的包大小
set global max_prepared_stmt_count=65528;
set global slave_parallel_workers=8; --增大复制并行度调整完成后开启第二次导入，在晚上21:31分，导入260G左右时再次异常终止，导入任务报错和第一次一样，数据库日志发现2节点在当时被kill掉一个session! 始终没想明白，一个简单的nohup mysql –uxxxx –pxxxx < xxxx.sql &为什么会异常终止。也未排查出该问题具体原因，有大师们碰到过这种类型的问题可以交流一下，初步判断还是云主机性能问题和MySQL性能瓶颈导致这种一次性导入500G大文件异常终止。
最终和客户沟通确认，将400多G大表做rename后导出前一个月数据再恢复至新集群中，因考虑到大文件导入性能问题，我们将该文件按行数切割后再依次分批导入(SQL文件切割针对单表不会导致数据被切断，但如果是按库导出，涉及到多个create table会存在切断的情况)，完成此次恢复工作。
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/129468.html
摘要：截至年底，贝壳金服业务已覆盖全国多个城市及地区，为超过万用户提供了金融服务。老机房下线完成则表示数据迁移完成。机房迁移实施过程操作描述配置防火墙，将两个机房所需端口开通。执行下线命令，一次性下线所有旧机房的。跨机房迁移，网络延迟不能高于。 作者介绍 ：李振环，贝壳金服数据基础架构负责人，目前负责数据平台和企业级数据仓库开发。 公司介绍 贝壳金服是专注居住场景的金融科技服务商，起步于2...
摘要：爱奇艺，中国高品质视频娱乐服务提供者，年月日正式上线，推崇品质青春时尚的品牌内涵如今已深入人心，网罗了全球广大的年轻用户群体，积极推动产品技术内容营销等全方位创新。边控中心是爱奇艺第一个在线业务使用的项目，所以我们制定了详细的上线计划。 爱奇艺，中国高品质视频娱乐服务提供者，2010 年 4 月 22 日正式上线，推崇品质、青春、时尚的品牌内涵如今已深入人心，网罗了全球广大的年轻用户群...
摘要：因为传统的数据库管理方式在当前这种架构下依靠手工或者借助简单的工具是无法应对多活架构大规模管理带来的复杂性，因此平台化显得非常重。我们在做的方案时做了充分调查及论证，最终没有选择这种方式。 蔡鹏，2015年加入饿了么，见证了饿了么业务&技术从0到1的发展过程，并全程参与了数据库及DBA团队高速发展全过程。同时也完成个人职能的转型-由运维DBA到DEV-DBA的转变,也从DB的维稳转变到专心为...
阅读 1250·2023-01-11 13:20
阅读 1559·2023-01-11 13:20
阅读 1013·2023-01-11 13:20
阅读 1680·2023-01-11 13:20
阅读 3972·2023-01-11 13:20
阅读 2520·2023-01-11 13:20
阅读 1356·2023-01-11 13:20
阅读 3486·2023-01-11 13:20
