安科网

一篇文章带你玩转TiDB灾难恢复

llliarby

llliarby

2020-05-11

关注 关注
一篇文章带你玩转TiDB灾难恢复

一、背景

高可用是 TiDB 的另一大特点，TiDB/TiKV/PD 这三个组件都能容忍部分实例失效，不影响整个集群的可用性。下面分别说明这三个组件的可用性、单个实例失效后的后果以及如何恢复。

TiDB
TiDB 是无状态的，推荐至少部署两个实例，前端通过负载均衡组件对外提供服务。当单个实例失效时，会影响正在这个实例上进行的 Session，从应用的角度看，会出现单次请求失败的情况，重新连接后即可继续获得服务。单个实例失效后，可以重启这个实例或者部署一个新的实例。

PD
PD 是一个集群，通过 Raft 协议保持数据的一致性，单个实例失效时，如果这个实例不是 Raft 的 leader，那么服务完全不受影响；如果这个实例是 Raft 的 leader，会重新选出新的 Raft leader，自动恢复服务。PD 在选举的过程中无法对外提供服务，这个时间大约是3秒钟。推荐至少部署三个 PD 实例，单个实例失效后，重启这个实例或者添加新的实例。

TiKV
TiKV 是一个集群，通过 Raft 协议保持数据的一致性（副本数量可配置，默认保存三副本），并通过 PD 做负载均衡调度。单个节点失效时，会影响这个节点上存储的所有 Region。对于 Region 中的 Leader 节点，会中断服务，等待重新选举；对于 Region 中的 Follower 节点，不会影响服务。当某个 TiKV 节点失效，并且在一段时间内（默认 30 分钟）无法恢复，PD 会将其上的数据迁移到其他的 TiKV 节点上。

二、架构

wtidb28.add.shbt.qihoo.net? 192.168.1.1? TiDB/PD/pump/prometheus/grafana/CCS
wtidb27.add.shbt.qihoo.net? 192.168.1.2? TiDB
wtidb26.add.shbt.qihoo.net? 192.168.1.3? TiDB
wtidb22.add.shbt.qihoo.net? 192.168.1.4? TiKV
wtidb21.add.shbt.qihoo.net? 192.168.1.5? TiKV
wtidb20.add.shbt.qihoo.net? 192.168.1.6? TiKV
wtidb19.add.shbt.qihoo.net? 192.168.1.7? TiKV
wtidb18.add.shbt.qihoo.net? 192.168.1.8? TiKV
wtidb17.add.shbt.qihoo.net? 192.168.1.9? TiFlash
wtidb16.add.shbt.qihoo.net? 192.168.1.10? TiFlash

集群采用3TiDB节点，5TiKV，2TiFlash架构来测试灾难恢复，TiFlash采用的方式是先部署集群，后部署TiFlash的方式，版本3.1.0GA

三、宕机两台测试

集群默认3副本，5台机器宕机任意两台，理论上存在三种情况，一种是3副本中，有两个副本正巧在宕机的这两台上，一种是3副本中，只有一个region在宕机的两台机器上，还一种就是宕机的两台机器里不存在某些内容的任何副本，本次我们测试让wtidb21和wtidb22两个TiKV节点宕机。

我们先看一下宕机前测试表的状况

mysql> select count(*) from rpt_qdas_show_shoujizhushou_channelver_mix_daily;
+----------+
| count(*) |
+----------+
|  1653394 |
+----------+
1 row in set (0.91 sec)

mysql> select count(*) from rpt_qdas_show_shoujizhushou_channelver_mix_daily force index (idx_day_ver_ch);
+----------+
| count(*) |
+----------+
|  1653394 |
+----------+
1 row in set (0.98 sec)

两台同时宕机后：

mysql> select count(*) from rpt_qdas_show_shoujizhushou_channelver_mix_daily;               
ERROR 9002 (HY000): TiKV server timeout 
mysql> select count(*) from rpt_qdas_show_shoujizhushou_channelver_mix_daily force index (idx_day_ver_ch);
ERROR 9005 (HY000): Region is unavailable

看一下宕机的两台store_id

/data1/tidb-ansible-3.1.0/resources/bin/pd-ctl -i -u http://192.168.1.1:2379
? store

知道是1和4

检查大于等于一半副本数在故障节点上的region

[ bin]$ /data1/tidb-ansible-3.1.0/resources/bin/pd-ctl  -u http://192.168.1.1:2379  -d region --jq=‘.regions[] | {id: .id, peer_stores: [.peers[].store_id] | select(length as $total | map(if .==(1,4) then . else empty end) | length>=$total-length)}‘
{"id":18,"peer_stores":[4,6,1]}
{"id":405,"peer_stores":[7,4,1]}
{"id":120,"peer_stores":[4,1,6]}
{"id":337,"peer_stores":[4,5,1]}
{"id":128,"peer_stores":[4,1,6]}
{"id":112,"peer_stores":[1,4,6]}
{"id":22,"peer_stores":[4,6,1]}
{"id":222,"peer_stores":[7,4,1]}
{"id":571,"peer_stores":[4,6,1]}

在剩余正常的kv节点上执行停kv的脚本：

ps -ef|grep tikv
sh /data1/tidb/deploy/scripts/stop_tikv.sh
ps -ef|grep tikv

变更其属主，将其拷贝至tidb目录下
chown -R tidb. /home/helei/tikv-ctl

这个分情况, 如果是 region 数量太多，那么按照 region 来修复的话，速度会比较慢，并且繁琐，这个使用使用 all 操作比较便捷，但是有可能误杀有两个 peer 的副本，也就是说可能你坏的这台机器，有个region只有一个在这台机器上，但他也会只保留一个region副本在集群里
下面的操作要在所有存活的节点先执行stop kv操作（要求kv是关闭状态），然后执行

[ tidb]$ ./tikv-ctl --db /data1/tidb/deploy/data/db unsafe-recover remove-fail-stores -s 1,4 --all-regions                                                                    
removing stores [1, 4] from configrations...
success

重启pd节点

ansible-playbook stop.yml --tags=pd
这里如果pd都关了的话，你是登不上库的
[ ~]$ /usr/local/mysql56/bin/mysql -u mydba -h 10.217.36.146 -P 43000 -p4c41b9
6c7687f66d 
…
…
…
ansible-playbook start.yml --tags=pd

重启存活的kv节点
sh /data1/tidb/deploy/scripts/start_tikv.sh

检查没有处于leader状态的region
[ bin]$ /data1/tidb-ansible-3.1.0/resources/bin/pd-ctl -u http://192.168.1.1:2379 -d region --jq ‘.regions[]|select(has("leader")|not)|{id: .id,peer_stores: [.peers[].store_id]}‘
这里我没有搜到任何的非leader region，只有副本数是3，且同时挂3台机器以上，且正巧有些region全部的region都在这3台机器上，前面步骤是unsafe all-region，pd这个检查没有处于leader状态的region步骤才会显示出来，才会需要对应到表查询丢了那些数据，才需要去创建空region啥的，我这个情况，只要还保留一个副本，不管unsafe执行的是all-regions，还是指定的具体的region号，都是不需要后面的步骤

正常启动集群后，可以通过pd-ctl来观看之前的region数，理论上在使用unsafe --all-regions后，仅剩的1个region成为leader，剩余的kv节点通过raft协议将其再次复制出2个follower拷贝到其他store上
例如本案例里的
{"id":18,"peer_stores":[4,6,1]}
通过pd-ctl可以看到他现在在犹豫1,4kv节点损坏，在执行unsafe-recover remove-fail-stores --all-regions后，将1,4的移除，仅剩的6成为leader，利用raft协议在5,7节点复制出新的follower，达成3副本顺利启动集群

? region 18
{
  "id": 18,
  "start_key": "7480000000000000FF0700000000000000F8",
  "end_key": "7480000000000000FF0900000000000000F8",
  "epoch": {
    "conf_ver": 60,
    "version": 4
  },
  "peers": [
    {
      "id": 717,
      "store_id": 6
    },
    {
      "id": 59803,
      "store_id": 7
    },
    {
      "id": 62001,
      "store_id": 5
    }
  ],
  "leader": {
    "id": 717,
    "store_id": 6
  },
  "written_bytes": 0,
  "read_bytes": 0,
  "written_keys": 0,
  "read_keys": 0,
  "approximate_size": 1,
  "approximate_keys": 0
}

如果只同时挂了2台机器，那么到这里就结束了，如果只挂1台那么不用处理的

先看一下数据现在是没问题的，之前的步骤恢复的很顺利

mysql> select count(*) from rpt_qdas_show_shoujizhushou_channelver_mix_daily;
+----------+
| count(*) |
+----------+
|  1653394 |
+----------+
1 row in set (0.86 sec)

mysql> select count(*) from rpt_qdas_show_shoujizhushou_channelver_mix_daily force index (idx_day_ver_ch);
+----------+
| count(*) |
+----------+
|  1653394 |
+----------+
1 row in set (0.98 sec)

这里有个插曲
当我把1,4宕掉的节点恢复，这期间集群一直没有新的数据写入，原本是6作为leader，新生成的5，7作为follower作为副本，而恢复后，将5,7剔除，重新将1,4作为follower了，region 18还是1,4,6的store_id。

四、宕机3台测试

如果同时挂了3台及以上，那么上面的非leader步骤检查是会有内容的
我们这次让如下三台宕机：

wtidb22.add.shbt.qihoo.net? 192.168.1.4? TiKV
wtidb21.add.shbt.qihoo.net? 192.168.1.5? TiKV
wtidb20.add.shbt.qihoo.net? 192.168.1.6? TiKV

首先，停止所有正常的tikv，本案例是wtidb19,wtidb18

看一下宕机的两台store_id

/data1/tidb-ansible-3.1.0/resources/bin/pd-ctl -i -u http://192.168.1.1:2379
? store

知道是1、4、5

检查大于等于一半副本数在故障节点上的region

[ bin]$  /data1/tidb-ansible-3.1.0/resources/bin/pd-ctl  -u http://192.168.1.1:2379  -d region --jq=‘.regions[] | {id: .id, peer_stores: [.peers[].store_id] | select(length as $total | map(if .==(1,4,5) then . else empty end) | length>=$total-length)}‘
{"id":156,"peer_stores":[1,4,6]}
{"id":14,"peer_stores":[6,1,4]}
{"id":89,"peer_stores":[5,4,1]}
{"id":144,"peer_stores":[1,4,6]}
{"id":148,"peer_stores":[6,1,4]}
{"id":152,"peer_stores":[7,1,4]}
{"id":260,"peer_stores":[6,1,4]}
{"id":480,"peer_stores":[7,1,4]}
{"id":132,"peer_stores":[5,4,6]}
{"id":22,"peer_stores":[6,1,4]}
{"id":27,"peer_stores":[4,1,6]}
{"id":37,"peer_stores":[1,4,6]}
{"id":42,"peer_stores":[5,4,6]}
{"id":77,"peer_stores":[5,4,6]}
{"id":116,"peer_stores":[5,4,6]}
{"id":222,"peer_stores":[6,1,4]}
{"id":69,"peer_stores":[5,4,6]}
{"id":73,"peer_stores":[7,4,1]}
{"id":81,"peer_stores":[5,4,1]}
{"id":128,"peer_stores":[6,1,4]}
{"id":2,"peer_stores":[5,6,4]}
{"id":10,"peer_stores":[7,4,1]}
{"id":18,"peer_stores":[6,1,4]}
{"id":571,"peer_stores":[6,5,4]}
{"id":618,"peer_stores":[7,1,4]}
{"id":218,"peer_stores":[6,5,1]}
{"id":47,"peer_stores":[1,4,6]}
{"id":52,"peer_stores":[6,1,4]}
{"id":57,"peer_stores":[4,7,1]}
{"id":120,"peer_stores":[6,1,4]}
{"id":179,"peer_stores":[5,1,4]}
{"id":460,"peer_stores":[5,7,1]}
{"id":93,"peer_stores":[6,1,4]}
{"id":112,"peer_stores":[6,1,4]}
{"id":337,"peer_stores":[5,6,4]}
{"id":400,"peer_stores":[5,7,1]}

现在还剩两台存活

wtidb19.add.shbt.qihoo.net? 192.168.1.7? TiKV
wtidb18.add.shbt.qihoo.net? 192.168.1.8? TiKV

下面的操作要在所有存活的节(本案例是wtidb19和wtidb18)点先执行stop kv操作（要求kv是关闭状态），然后执行

[ tidb]$ ./tikv-ctl --db /data1/tidb/deploy/data/db unsafe-recover remove-fail-stores -s 1,4,5 --all-regions                                                                 
removing stores [1, 4, 5] from configrations...
success

重启pd节点

ansible-playbook stop.yml --tags=pd
ansible-playbook start.yml --tags=pd

重启存活的kv节点
sh /data1/tidb/deploy/scripts/start_tikv.sh

检查没有处于leader状态的region，这里看到，1,4,5因为所有的region都在损坏的3台机器上，这些region丢弃后数据是恢复不了的

[ tidb-ansible-3.1.0]$ /data1/tidb-ansible-3.1.0/resources/bin/pd-ctl  -u http://192.168.1.1:2379 -d region --jq ‘.regions[]|select(has("leader")|not)|{id: .id,peer_stores: [.peers[].store_id]}‘
{"id":179,"peer_stores":[5,1,4]}
{"id":81,"peer_stores":[5,4,1]}
{"id":89,"peer_stores":[5,4,1]}

根据region ID，确认region属于哪张表

[ tidb-ansible-3.1.0]$ curl http://192.168.1.1:10080/regions/179
{
 "region_id": 179,
 "start_key": "dIAAAAAAAAA7X2mAAAAAAAAAAwOAAAAAATQXJwE4LjQuMAAAAPwBYWxsAAAAAAD6A4AAAAAAAqs0",
 "end_key": "dIAAAAAAAAA7X3KAAAAAAAODBA==",
 "frames": [
  {
   "db_name": "hl",
   "table_name": "rpt_qdas_show_shoujizhushou_channelver_mix_daily(p201910)",
   "table_id": 59,
   "is_record": false,
   "index_name": "key2",
   "index_id": 3,
   "index_values": [
    "20191015",
    "8.4.0",
    "all",
    "174900"
   ]
  },
  {
   "db_name": "hl",
   "table_name": "rpt_qdas_show_shoujizhushou_channelver_mix_daily(p201910)",
   "table_id": 59,
   "is_record": true,
   "record_id": 230148
  }
 ]
}

这时候去看集群状态的话，

? store
{
  "count": 5,
  "stores": [
    {
      "store": {
        "id": 1,
        "address": "192.168.1.4:20160",
        "version": "3.1.0",
        "state_name": "Down"
      },
      "status": {
        "leader_weight": 1,
        "region_count": 3,
        "region_weight": 1,
        "start_ts": "1970-01-01T08:00:00+08:00"
      }
    },
    {
      "store": {
        "id": 4,
        "address": "192.168.1.5:20160",
        "version": "3.1.0",
        "state_name": "Down"
      },
      "status": {
        "leader_weight": 1,
        "region_count": 3,
        "region_weight": 1,
        "start_ts": "1970-01-01T08:00:00+08:00"
      }
    },
    {
      "store": {
        "id": 5,
        "address": "192.168.1.6:20160",
        "version": "3.1.0",
        "state_name": "Down"

监控也是没数据

库里查询也依旧被阻塞

mysql> use hl
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed
mysql> select count(*) from rpt_qdas_show_shoujizhushou_channelver_mix_daily;

创建空region解决unavaliable状态，这个命令要求pd，kv处于关闭状态
这里必须一个一个-r的写，要不报错：

[ tidb]$ ./tikv-ctl --db /data1/tidb/deploy/data/db recreate-region -p 192.168.1.1:2379 -r 89,179,81
thread ‘main‘ panicked at ‘called `Result::unwrap()` on an `Err` value: ParseIntError { kind: InvalidDigit }‘, src/libcore/result.rs:1188:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
Aborted

./tikv-ctl --db /data1/tidb/deploy/data/db recreate-region -p ‘192.168.1.1:2379‘ -r 89
./tikv-ctl --db /data1/tidb/deploy/data/db recreate-region -p ‘192.168.1.1:2379‘ -r 81
./tikv-ctl --db /data1/tidb/deploy/data/db recreate-region -p ‘192.168.1.1:2379‘ -r 179

启动pd和tikv后，再次运行
[ tidb-ansible-3.1.0]$ /data1/tidb-ansible-3.1.0/resources/bin/pd-ctl -u http://192.168.1.1:2379 -d region --jq ‘.regions[]|select(has("leader")|not)|{id: .id,peer_stores: [.peers[].store_id]}‘
没有任何结果则符合预期

这里再次查询可以看到丢了数据，因为我们有几个region（81,89,179）都丢失了

mysql> select count(*) from rpt_qdas_show_shoujizhushou_channelver_mix_daily;
+----------+
| count(*) |
+----------+
|  1262523 |
+----------+
1 row in set (0.92 sec)

这里可以看到索引数据不再region（81,89,179）中，所以还跟之前一样

mysql> select count(*) from rpt_qdas_show_shoujizhushou_channelver_mix_daily force index (idx_day_ver_ch);
+----------+
| count(*) |
+----------+
|  1653394 |
+----------+
1 row in set (1.01 sec)

至此，测试完成

五、总结

看完这篇文章，相信你不会再虚TiDB的多点掉电问题的数据恢复了，正常情况下，极少数出现集群同时宕机多台机器的，如果只宕机了一台，那么并不影响集群的运行，他会自动处理，当某个 TiKV 节点失效，并且在一段时间内（默认 30 分钟）无法恢复，PD 会将其上的数据迁移到其他的 TiKV 节点上。但如果同时宕机两台，甚至3台及以上，那么看过这篇文章的你相信你一定不会再手忙脚乱不知所措了！~

tidb

llliarby

llliarby

0 关注 0 粉丝 0 动态

关注 关注

相关推荐

HBase/TiDB都在用的数据结构：LSM Tree，不得了解一下？

LSM Tree广泛应用在HBase，TiDB等诸多数据库和存储引擎上，我们先来看一下它的一些应用：。这么牛X的名单，你不想了解下LSM Tree吗？装X之前，我们先来了解一些基本概念。设计数据存储系统可能需要考虑的一些问题有：ACID，RUM。读性能体现

晨曦之星 2020-08-14

TiDB in Kubernetes 文档

在阿里云上部署 TiDB 集群

zccheu 2020-06-11

一篇文章带你玩转TiDB灾难恢复

高可用是 TiDB 的另一大特点，TiDB/TiKV/PD 这三个组件都能容忍部分实例失效，不影响整个集群的可用性。TiDBTiDB 是无状态的，推荐至少部署两个实例，前端通过负载均衡组件对外提供服务。TiKVTiKV 是一个集群，通过 Raft 协议保持

zhaoenweiex 2020-05-12

TiDB

使用Docker Compose快速搭建一个单机

魂影魔宅 2020-05-11

分布式 NewSQL 数据库 UCloud TiDB Service 是如何炼成的？

TiDB 是 PingCAP 公司研发的开源分布式关系型数据库，结合了传统的 RDBMS 和 NoSQL 的最佳特性。TiDB 兼容 MySQL，具备「分布式强一致性事务、在线弹性水平扩展、故障自恢复的高可用、跨数据中心多活」等核心特性，是大数据时代理想的

亦碎流年 1评论 2019-12-27

汽车之家从 SQL Server 到 TiDB 的异构变迁

SQL Server + .Net 是很多早期互联网企业的标配技术栈，但是随着业务的不断扩大，这种技术栈会遇到很多挑战，我们可能需要换个数据库。本文从业务背景、迁移方案、同步、业务改造、上线效果、周边建设等多个角度，详细介绍了如何从 SQL Server

Jhonse技术 2019-12-05

诊断修复 TiDB Operator 在 K8s 测试中遇到的 Linux 内核问题

Kubernetes是一个开源容器编排系统，可自动执行应用程序部署、扩展和管理。它是云原生世界的操作系统。K8s 或操作系统中的任何缺陷都可能使用户进程存在风险。作为 PingCAP EE团队，我们在 K8s 中测试 TiDB Operator时，发现了两

godwot 2019-11-19

TiDB Binlog 组件正式开源，前排开“坑”走起！

利用 TiDB Binlog 可以实现数据准实时同步到其他数据库，以及 TiDB 数据准实时的备份与恢复。TiDB Binlog 作为 TiDB 的核心组件之一，已经在上百家用户的生产环境中长时间稳定运行。为方便用户和开发者更加深入理解和使用 TiDB B

Commander 2019-11-18

TiDB TechDay 巡讲启动！六城一起 High~

我感到自豪，因为我取得了第一个胜利，我毫不怀疑胜利是会接踵而至的。我做到了第一件做不到的事情，我也可以接着做下去。——王小波《我在荒岛上迎接黎明》。TiDB 的设计灵魂，是让优雅灵活的架构充满无限可能性。从大规模业务场景中稳定使用的 TiDB 2.0 版本

llliarby 2019-11-17

微众银行数据库架构演进及 TiDB 实践经验

硕士毕业于华中科技大学，毕业后加入腾讯，任高级工程师，从事分布式存储与云数据库相关的研发与运营工作；2014 年加入微众银行，负责微众银行的数据库平台的建设与运营。2015 年加入微众银行担任高级 DBA，负责监控优化、性能优化以及新技术预研，目前致力于行

zhaoenweiex 2019-11-03

TiDB + TiFlash ： 朝着真 HTAP 平台演进

在互联网浪潮出现之前，企业的数据量普遍不大，特别是核心的业务数据，通常一个单机的数据库就可以保存。所以从某种程度上说，大数据技术可以算是传统关系型数据库技术发展过程的一个分支。当然在过程中大数据领域也发展出了属于自己的全新场景，诞生了许多新的技术，这个不深

wagpig 2019-11-03

高效编排有状态应用——TiDB 的云原生实践与思考

曾负责酷家乐数据同步平台与容器监控系统的研发。云原生时代以降，无状态应用以其天生的可替换性率先成为各类编排系统的宠儿。这种基础能力的下沉无疑是对应用开发者生产力的又一次解放。而 PD 则是集群的大脑，它接收 TiKV 进程上报的存储信息，并计算出整个集群中

IT兄弟团 2019-10-29

我们是如何设计 Golang & SQL 引擎课程的？ | Talent Plan 背后的故事

在上篇文章中我们介绍了 PingCAP Talent Plan - TiKV 方向的课程内容，本文将从课程设计的角度和大家聊一聊 TiDB 方向的课程内容，包括课程设计的逻辑，和课程学习过程中常见的问题及解答等。TiDB 作为一个支持 MySQL 协议，以

programmerv 2019-09-07

云上 TiDB 管理「利器」，TiDB Operator 1.0 GA 发布

去年八月份，我们 开源了 TiDB Operator 项目，以实现 TiDB 在 Kubernetes 上的部署和运维。开源后到现在的近一年内，我们一方面基于用户反馈不断打磨项目的易用性，另一方面通过严苛的稳定性测试持续提升可靠性。今天，我们自豪地宣布 T

dirk0 2019-09-07

贝壳金服 TiDB 在线跨机房迁移实践

公司介绍贝壳金服是专注居住场景的金融科技服务商，起步于2006年成立的链家金融事业部，并于 2017年3月正式独立运营。截至2018年底，贝壳金服业务已覆盖全国90多个城市及地区，为超过130万用户提供了金融服务。现有集群已经使用 100 多个 Synce

BusterZR 2019-07-01

PingCAP University 免费开放线上课程，快来点亮「TiDB DBA」技能点吧！

去年年底 我们启动了 PingCAP University 培训认证计划，获得了社区伙伴们的广泛响应。PingCAP University 已经开展五期线下培训，百余名学员在 PingCAP 北京&上海 Office 参加了为期 4 天的 PCTP

BusterZR 2019-07-01

TiDB 在银行核心金融领域的研究与两地三中心实践

当前主要研发方向集中在构建先进、高效、面向 OLTP 的银行交易系统，提升银行信息系统服务能力。本文整理自于振华老师在TiDBDevCon2019 上的演讲实录，演讲主题为《TiDB 在银行核心金融领域的研究与实践》。

魂影魔宅 2019-07-01

TiDB 3.0.0 Beta.1 Release Notes

2019 年 03 月 26 日，TiDB 发布 3.0.0 Beta.1 版，对应的 TiDB-Ansible 版本为 3.0.0 Beta。相比 3.0.0 Beta 版本，该版本对系统稳定性、易用性、功能、优化器、统计信息以及执行引擎做了很多改进。支

wwy0 2019-07-01

What’s New in TiDB 3.0.0 Beta.1

今年 1 月份，我们发布了 TiDB 3.0.0 Beta 版本，DevCon 上也对这个版本做了介绍，经过两个月的努力，今天推出了下一个 Beta 版本 3.0.0 Beta.1。让我们看一下这个版本相比于之前有什么改进。新增特性解读Skyline Pr

zhaoenweiex 2019-07-01

DM 源码阅读系列文章（一）序

前言TiDB-DM 是由 PingCAP 开发的一体化数据同步任务管理平台，支持从 MySQL 或 MariaDB 到 TiDB 的全量数据迁移和增量数据同步，在 TiDB DevCon 2019 正式开源。作为一款连接 MySQL/MariaDB 生态和

魂影魔宅 2019-07-01
llliarby

llliarby

W3CSchool教程
HTML 教程
CSS 教程
Bootstrap 教程
Javascript 教程
jQuery 教程
后端教程
C 教程
Java 教程
PHP 教程
Python 教程
Go 教程
移动开发
Android 教程
Swift 教程
Kotlin 教程
jQuery Mobile 教程
ionic 教程
关于我们
新闻动态
联系方式
招聘英才
安科实验室
帮助与反馈

安科网(Ancii)，中国第一极客网

Copyright © 2013 - 2019 Ancii.com

京ICP备18063983号 京公网安备11010802014868号