单片机|GitHub生产数据库架构优化和数据迁移( 三 ) excel|操作系统|内存条

通过使用MySQL的常规复制功能将数据提供给另一个集群。最初，新集群被添加到旧集群的复制树中。然后脚本会快速执行一系列更改以实现切换。

在运行脚本之前，先准备应用程序和数据库复制，同一个复制的集群cluster_b是做为现有集群cluster_a的子集群. 用ProxySQL将客户端连接多路复用连接到 MySQL主数据库。 cluster_b的ProxySQL配置为将流量路由到主cluster_a集群。 ProxySQL使得能够快速更改数据库流量路由，并且对数据库客户端的影响最小。
通过这种设置，可以将数据库连接移动到cluster_b而无需改动任何东西。所有读取流量仍然流向从cluster_a基本的。所有写入流量都保留在cluster_a 。
然后运行一个执行以下内容的转换脚本：
启用只读模式 cluster_a基本的。此时，所有写入cluster_a和cluster_b被阻止。所有尝试写入这些数据库主数据库的Web请求都失败并导致500报错。
从主集群cluster_a查看上次执行的MySQL GTID 。
查询luster_b验证最后执行的GTID是否同步。
停止从cluster_a到cluster_b的主从复制。
更新 ProxySQL 路由配置将流量引导至cluster_b 。
解除cluster_a和 cluster_b的只读模式。
经过充分的准备和练习，对于最繁忙的数据库表，通过这六个步骤可以在几十毫秒内实现数据切换。由于在一天中流量最低的时间执行此类转换，因此只会由于写入失败而导致少数面向用户的错误。该方法的结果比预期的要好。
经验教训数据迁移过程中主要使用了write-cutover过程用于拆分mysql1集群。一次迁移了130个最繁忙的表及其支持GitHub的核心功能：存储库、问题和拉取请求。这个过程是作为一种风险缓解策略而创建的。
由于部署拓扑和读写支持等因素，实际中优化方案中并没有选择Vitess作为在每种情况下移动数据库表的工具。预计将来有机会将其用于大多数数据迁移。
结果【单片机|GitHub生产数据库架构优化和数据迁移】通过使用虚拟分区和多个inter检查器， GitHub数据库被划分成不同的Schema域实现不同业务的数据库横向分库。通过Vitess和自定义write-cutover过程实现具体分库的数据迁移，同时实现了数据架构的升级，升级后数据查询QPS由之前的95w/s到现在的120w/s集群主机的平均负载也减少一半，性能上获得极大的提高，用户的响应和体验都得到极大改善。其数据架构升级过程和所用的工具也都是开源工具（比如ProxySQL ， Vitess等），可供大家直接拿来直接使用。