TDSQL 另外一个辅助个性：数据同步和备份。

TDSQL 数据同步组件

数据同步的重点分为三个场景：

第一个场景是一个数据汇总。 比方，多个数据库实例的数据同步到一个数据库实例，如保险行业用户多喜爱将全国多个区域数据库实例的数据同步到全国总库进行统计分析。

第二个就是跨城的容灾。 跨城容灾，个别一个城市的分布式数据库的数据须要同步到另外一个城市异构的分布式数据库中做灾备。有的时候咱们要做异构数据库的跨城容灾，比如说主城是一个十六节点的数据库，它十分宏大。然而备城，可能咱们基于老本思考，选用的设施数量、机房都要差一些。

比方灾备实例只有两个物理分片。一个是两分片数据库实例，而另外一个时十六分片的数据库实例。从十六分片同步到；两分片，这是一个异构的数据库的同步，这时候咱们就须要利用数据同步这个组件。

第三个是迁徙。 异构数据库的迁徙，将数据从 TDSQL 同步到 MySQL、Oracle、PostgreSQL 等数据库。当然，从 TDSQL 到 TDSQL 是一种同步形式，更有一种是 TDSQL 到其余异构数据库。举个例子，张家港农商行，它的外围零碎须要从传统的国外商用数据库替换为 TDSQL，可能还是须要做肯定的危险的防备。

最终咱们给了一套用 Oracle 作为 TDSQL 灾备示例的计划，通过数据同步组件，将 TDSQL 的数据准实时同步到 Oracle。如果在极其状况下须要将业务切到 Oracle，咱们也是有这个能力的。

当然数据迁徙也体现了 TDSQL 凋谢的思维，既然容许用户将数据迁徙到 TDSQL，如果有一天用户可能感觉 TDSQL 不是很好，感觉有更好的产品能够代替它，TDSQL 反对用户把数据迁走。

TDSQL 数据备份

TDSQL 反对在线的实时热备，同时这个备份是基于备机上做的备份，备份反对镜像和 binlog 的备份。镜像又反对物理镜像和逻辑镜像（也叫物理备份和逻辑备份）。

物理备份的益处是速度快，间接操纵物理文件，毛病是只能备份整个数据库实例，无奈抉择指定库表。逻辑备份的益处是通过 SQL 的形式备份，它能够抉择单个库表备份，然而如果对整个实例备份效率不迭物理备份。比如说有 1T 的数据，只有 100 兆是我的要害的数据，如果为了节俭存储空间就没有必要用物理备份，就用逻辑备份，只备份咱们关怀的库表。

有了物理备份和逻辑备份之后，基于数据的镜像，再联合 binlog 轻松实现数据的定点复原。对于 binlog 的备份 TDSQL 的 Agent 模块实现准实时的异步备份。比如说咱们每天的 0 点备份镜像，同时各个时间段的 binlog 准实时备份。当须要复原到一个早上 6 点的数据，利用 0 点的数据镜像再联合 0 点到 6 点的 binlog，即可实现 6 点的数据恢复。

备份是在备机上做不会影响主机。整个备份过程也是有监控有告警，实现整个备份过程的追踪。

因为架构这一块内容的确是比拟多，本次也作为所有 TDSQL 系列分享的一个前瞻，前面更多的系列分享会依据这门课的局部章节具体开展。这次分享次要是想帮忙大家理解 TDSQL 的整体架构和模块划分，以及它的要害个性是如何设计，是基于什么样的思考。听完本次分享再听前面的专题，会更容易去了解。

Q&A

Q：TDSQL 1.0 版本没有 SQL 引擎模块吧？

A：最早在 2002 年的时候咱们应用单机版 MySQL 作为数据存取服务，而后衍生出了 TDSQL，这种计算存储相拆散的架构，进而引入 SQL 引擎。

Q：请问存储节点的 MySQL 是应用官网原生的么？

A：TDSQL 在原生 MySQL 根底上做了大量调优，如线程池、强同步的优化，以及平安限度，分布式事务 XA 优化等等。

Q：银行外围要做到分库分表，开发的聚合查问如何实现？

A：SQL 引擎屏蔽了分表的细节，让业务在逻辑上看到的和单节点模式一下一样，依然是一张独立的库表。此外，SQL 引擎会主动做数据聚合，业务开发不须要关怀。

Q：a+3，如果掉失了，B 和 C 节点都没有同步过去，怎么办？A 机器曾经曾经无奈复原。

A：a+ 3 如果没有被 B,C 确认，即不满足被多数派确认，是不会应答给业务胜利的，最终会以超时的谬误返回给业务。如果 A 机器无奈复原，这时新退出节点会通过物理拷贝形式最快速度“克隆”出一个备节点持续代替 A 节点提供服务。

Q：Shard 版本的能够通过 pt 工具，或者 gh-ost 加字段不？会有什么限度不？

A：TDSQL 治理台提供 online ddl 的性能，会主动对多分片做原子性变更，不须要业务再用第三方工具；分布式 TDSQL 在做 DDL 的时候不容许调整 shardkey 字段，比方原来以 id 作为 shardkey，当初要调整成 name 作为 shardkey，这样是不容许的。

Q：TDSQL Shard 算法有几种？建表语句必须须要批改语法吗？

A：TDSQL shard 算法对业务屏蔽，即基于 MySQL 分区表做的 hash 拆分（该算法不容许用户批改），这么做也是为了对业务屏蔽 TDSQL 分表细节。这里并不是限度用户只能做基于 hash 的分区，用户能够在 TDSQL-shard 的根底上做二级分区（比方：依照日期、工夫）。建表以及应用方面的语法，前面有一门对于分布式开发的课程，敬请期待。

Q：谁来解决 zk 的可靠性？

A：一方面，zk 本身做了高可用跨机房部署，同时奇数个 zk 部署当产生故障时只有残余存活 zk 数量大于集群 zk 的一半，zk 就能够持续提供服务；另外一方面，就算 zk 节点全副宕机，各个模块本身对 zk 也不是强依赖的，即 zk 在不工作的状况下，数据库实例的失常读写申请不会受到任何影响，只是不能解决切换、扩容等调度相干的触发式操作。

Q：老师方才讲两种模式，如果是用 Shard 模式，应用层对 Sql 语法有要求？是我听错了吗？

A：兼容 MySQL 99% 的 SQL 语法，shard 模式与 noshard 模式最次要的区别是 shardkey 的引入。引入 shardkey 之后，为了施展出 shard 模式下的性能劣势，倡议所有 sql 都带 shardkey 拜访，同时在 shard 模式下，一些数据库的高级个性如：存储过程、触发器、视图等个性会受到肯定的应用限度。更具体的内容前面会有专门的分布式开发的课程会专门介绍。

Q：分支到总行数据同步汇总，Oralce 同步到 TDSQL 是双向都反对么？

A：反对双向同步。这里的反对是有条件的，从 TDSQL 到 Oracle 是能够做到准实时同步，然而从 Oracle 到 TDSQL 目前还无奈做到准实时同步，后续会反对。

Q：分布式表和非分布式表如何做 join？

A：分布式 TDSQL 下存在两种表别离是大表和小表，大表就是 shard 表（分布式表），小表又叫播送表，会冗余到所有数据节点上。分布式表和非分布式表做 join 时，因为分布式表所在的物理节点上存在非分布式表的一份冗余，因此能够在单个数据节点上实现 join。

Q：是否反对自建公有云？如果私有云，老本会不会回升？

A：反对公有云的，TDSQL 大部分的银行客户都是采纳公有云部署模式，并和外网隔离。私有云的老本相比公有云显著是前者更低，像公有云须要自建机房，搭建光纤设施，然而益处是独占物理硬件资源。私有云的话都是和私有云上的其余用户专用一套 IDC、网络环境。

Q：是否反对 K8S 部署？

A：TDSQL 自带了一键部署解决方案，不依赖 K8S。

Q：分局分表反对大表关联查问吗？

A：反对的