适用场景
本文适用于在极端环境下，KunDB 无法启动，且多种方案均无法恢复的场景，包括 raft 重组，relay-log 清理等
Raft KunDB-CE均适用（ 版本 >= KunDB 2.1.4 ），其他版本待验证
至少需要满足如图的情况，pod 内执行
ps -ef | cat | grep socket
底层 mysqld 服务可以正常启动
操作步骤
- 确认故障的 KunDB，一般表现为 0/1 Running
-
每个KunDB的pod，都需要重复以下步骤：
- 进入 pod 内部，根据 socket 连接底层
mysql --socket=/vdir/mnt/disk1/kundb1/kundbdata/mysql.sock- 如果是 2.1.6 及以上的版本，还需要加上 socket 密码
-p'TEwD8*9#Qm!Pd&AG'- 查询当前节点流水
show master status \G;
- 选择流水最大的节点，并备份数据
nohup mysql -N -e "show databases;" --socket=/vdir/mnt/disk1/kundb1/kundbdata/mysql.sock 2>/dev/null| grep -Evx "information_schema|mysql|_vt|performance_schema|sys"|xargs mysqldump --socket=/vdir/mnt/disk1/kundb1/kundbdata/mysql.sock --single-transaction --source-data=2 --set-gtid-purged=off --skip-add-drop-table --hex-blob --triggers --routines --databases > alldata.sql &
- 备份权限和用户（Manager-KunDB 可以忽略此步）
mysql -N -e "select distinct user from mysql.user" --socket=/vdir/mnt/disk1/kundb1/kundbdata/mysql.sock -p'TEwD8*9#Qm!Pd&AG'| grep -Evx "clone_user|vt_app|orc_client_user|root|vt_repl|mysql.infoschema|mysql.session|mysql.sys|vt_allprivs|vt_appdebug|vt_dba|vt_filtered|kundb_dba|vt_meta_user|kun_monitor"|xargs -I {} mysql -N --socket=/vdir/mnt/disk1/kundb1/kundbdata/mysql.sock -p'TEwD8*9#Qm!Pd&AG' -e 'show create user {}' |awk '{print $0";"}' > createuser.sql
mysql -N -e "select distinct user from mysql.user" --socket=/vdir/mnt/disk1/kundb1/kundbdata/mysql.sock -p'TEwD8*9#Qm!Pd&AG'| grep -Evx "clone_user|vt_app|orc_client_user|root|vt_repl|mysql.infoschema|mysql.session|mysql.sys|vt_allprivs|vt_appdebug|vt_dba|vt_filtered|kundb_dba|vt_meta_user|kun_monitor"|xargs -I {} mysql -N --socket=/vdir/mnt/disk1/kundb1/kundbdata/mysql.sock -p'TEwD8*9#Qm!Pd&AG' -e 'show grants for {}' |awk '{print $0";"}' > grants.sql
-
将备份的sql文件移动到持久化目录
-
在新装的 KunDB 中 source 备份的 sql 文件即可恢复数据
完整性检查
使用 tail 命令检查备份的 alldata.sql 文件，正确备份的文件会在末尾输出
“Dump completed on XXXXXXX”
如果没有相关内容，则代表备份进程仍在进行中，或者因某些故障而中断，例如密码错误、socket 指定路径错误等，请检查相关命令
同样使用 tail 命令检查备份的 createuser.sql 与 grants.sql 文件，里面有完整的 sql 语句即可