Lightning断点续传

当Lighting备份过程中，如果数据量较大， 恢复可能要耗时数个小时甚至数天，长时间的运行程序可能由于实例OOM、或者程序异常等原因导致中断，如果每次重启都从头开始，就会浪费掉之前已成功导入的数据。此时断点续传功能会有非常好的效果；

如果恢复过程中发生异常中断，重新恢复的时候会报错：

[2022/02/21 10:53:37.556 +08:00] [ERROR] [main.go:90] ["tidb lightning encountered error"] [error="tidb-lightning pre-check failed. Please fix the failed check(s) or set --check-requirements=false to skip checks"]

 

报错提示TiDB Lightning 检测到表有非法的checkpoints， 如果避免丢数据，需要使用--checkpoint-remove参数；

• --checkpoint-error-destory: 失败的表从头开始重新导入
• --checkpoint-error-ignore:    清除出错状态，忽略之前的错误继续导入。  传入all会对所有的表进行上述操作；
• --checkpoint-remove: 无论是否出错，把表的断点清除；

这里执行-checkpoint-error-destory=all来对所有的表从头开始重新导入；

tidb-lightning-ctl -checkpoint-error-destroy=all  -config tidb-lightning.toml 

执行后，再重新执行tidb-lightning进行导入；

nohup tidb-lightning --check-requirements=false -config tidb-lightning.toml > nohup.out &

完成后，tidb-lightning.log末尾显示：

[2022/02/21 11:17:53.734 +08:00] [INFO] [main.go:93] ["tidb lightning exit"]

表示断点导入成功；

验证

1， 登陆tidb,验证同步到库表数据是否完整； 

2， tidb中多了一个schema:lightning_metadata ;

里面的表table_meta记录的同步各个表的结果；同步完成status字段会显示restore_finished

mysql> select * from lightning_metadata.table_meta order by task_id desc limit 1\G
*************************** 1. row ***************************
         task_id: 1645411910509609130
        table_id: 2432
      table_name: `jcdp_bak`.`application_metriceos`
     row_id_base: 0
      row_id_max: 0
  total_kvs_base: 0
total_bytes_base: 0
   checksum_base: 0
       total_kvs: 0
     total_bytes: 0
        checksum: 0
          status: restore_finished
1 row in set (0.01 sec)