TDSQL 数据同步和备份

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

1.TDSQL 数据同步组件

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

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

**第二个就是跨城的容灾。**跨城容灾，一般一个城市的分布式数据库的数据需要同步到另外一个城市异构的分布式数据库中做灾备。有的时候我们要做异构数据库的跨城容灾，比如说主城是一个十六节点的数据库，它非常庞大。但是备城，可能我们基于成本考虑，选用的设备数量、机房都要差一些。比如灾备实例只有两个物理分片。一个是两分片数据库实例，而另外一个时十六分片的数据库实例。从十六分片同步到；两分片，这是一个异构的数据库的同步，这时候我们就需要利用数据同步这个组件。

**第三个是迁移。**异构数据库的迁移，将数据从 TDSQL 同步到 MySQL、Oracle、PostgreSQL 等数据库。当然，从 TDSQL 到 TDSQL 是一种同步方式，更有一种是 TDSQL 到其他异构数据库。举个例子，张家港农商行，它的核心系统需要从传统的国外商用数据库替换为 TDSQL，可能还是需要做一定的风险的防范。最终我们给了一套用 Oracle 作为 TDSQL 灾备示例的方案，通过数据同步组件，将 TDSQL 的数据准实时同步到 Oracle。假如在极端情况下需要将业务切到 Oracle，我们也是有这个能力的。

当然数据迁移也体现了 TDSQL 开放的思想，既然允许用户将数据迁移到 TDSQL，如果有一天用户可能觉得 TDSQL 不是很好，觉得有更好的产品可以替代它，TDSQL 支持用户把数据迁走。

2.TDSQL 数据备份

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

物理备份的好处是速度快，直接操纵物理文件，缺点是只能备份整个数据库实例，无法选择指定库表。逻辑备份的好处是通过 SQL 的方式备份，它可以选择单个库表备份，但是如果对整个实例备份效率不及物理备份。比如说有 1T 的数据，只有 100 兆是我的关键的数据，如果为了节省存储空间就没有必要用物理备份，就用逻辑备份，只备份我们关心的库表。

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

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

因为架构这一块内容确实是比较多，本次也作为所有 TDSQL 系列分享的一个前瞻，后面更多的系列分享会根据这门课的部分章节详细展开。这次分享主要是想帮助大家了解 TDSQL 的整体架构和模块划分，以及它的关键特性是如何设计，是基于什么样的考虑。听完本次分享再听后面的专题，会更容易去理解。

3.Q&AQ：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：支持的