关于mysql:MySQL-亿级数据迁移之迁移策略

9次阅读

共计 1804 个字符，预计需要花费 5 分钟才能阅读完成。

子项目提供数据同步接口，可依据状况抉择同步的线程数以及批量插入的数据量。
具体步骤：

全量迁徙：搬迁以后库中所有的历史数据（新我的项目提供数据迁徙的接口，可批量迁徙数据，该过程会搬掉库中大部分数据）
增量迁徙：记录全量迁徙开始的工夫，搬迁全量迁徙过程中变更了的数据
数据比对：通过接口比对 Cassandra 和 MySQL 中的数据，最终数据一致性达到肯定 99.99% 以上
开双写：通过数据比对确保全量迁徙和增量迁徙没问题当前，关上双写。如果双写有问题，数据比对还能够发现双写中的问题。
切 Cassandra 读：确保双写没问题当前，敞开 MySQL 写。

5 个线程，每个线程 150 条数据，一个小时，808 万条数据，13.4 万 / 分钟
5 个线程，每个线程 500 条数据，15 分钟，274 万条数据，22.8 万 / 分钟
应用 Spring-data-cassandra 连贯驱动时速度过慢，查看后发现，Spring-data-cassandra 的 API 中，批量插入操作，外部实现是一条一条插入的

在本机运行，批改 Cassandra 并发读和并发写的线程数为 32，每次批量数据大小为 5000kb, 读写超时揭示为 500000 毫秒，测试后果如下：

应用一个节点

  10 个线程，查问 5000，每次 1000，三分钟，137 万 45.6 万 / 分  1000 万条数据 21.9 分钟
  10 个线程，查问 5000，每次 2000，两分钟，76 万 38 万 / 分     1000 万条数据 26.3 分钟
  6 个线程，查问 5000，每次 2000，二分钟，99 万 50 万 / 分      1000 万条数据 20 分钟
  6 个线程，查问 5000，每次 5000，一分钟，52 万 52 万 / 分      1000 万条数据 19.2 分钟
  5 个线程，查问 5000，每次 1000，7 分钟，400 万 57 万 / 分     1000 万条数据 17.5 分钟
  5 个线程，查问 5000，每次 2000，一分钟，56 万 56 万 / 分     1000 万条数据 17.8 分钟
  5 个线程，查问 5000，每次 5000，一分钟，36 万 36 万 / 分     1000 万条数据 27.7 分钟

减少到两个节点：

  5 个线程，查问 5000，每次 5000，十分钟，790 万 79 万 / 分   1000 万条数据 12.6 分钟
  5 个线程，查问 10000，每次 5000，十分钟，632 万 63.2 万 / 分 1000 万条数据 15.8 分钟
  10 个线程，查问 5000，每次 5000，十分钟，650 万 65 万 / 分   1000 万条数据 15.3 分钟

敞开 commitLog，两个节点

 5 个线程，查问 5000，每次 5000，十分钟，760 万 76 万 / 分    1000 万条数据 13.1 分钟

敞开 commitLog，一个节点

  5 个线程，查问 5000，每次 5000，十分钟，690 万 69 万 / 分 1000 万条数据 14.5 分钟
  5 个线程，查问 5000，每次 5000，2.5 分钟，110 万，44 万 / 分 1000 万条数据 22.7 分钟
  5 个线程，查问 1000，每次 5000，3 分钟，133 万，44 万 / 分 1000 万条数据 22.7 分钟
  5 个线程，查问 10000，每次 5000，3 分钟，84 万，28 万 / 分 1000 万条数据 35.7 分钟
  10 个线程，查问 10000，每次 5000，2 分钟，87 万，43.5 万 / 分 1000 万条数据 22.9 分钟

服务器上运行，三个节点

  5 个线程，查问 10000，每次 5000，80 万 / 分钟 1000 万条数据 12.5 分钟
  5 个线程，查问 20000，每次 5000，85 万 / 分钟 1000 万条数据 11.8 分钟
  5 个线程，查问 10000，每次 10000，80 万 / 分钟 1000 万条数据 12.5 分钟
  10 个线程，查问 10000，每次 5000，76 万 / 分钟 1000 万条数据 13.1 分钟

应用 Scylla-driver 驱动，速度与 Cassandra-driver 基本一致

## 总结