简介

TDSQL for MySQL是部署在腾讯云上的一种支持自动水平拆分、Shared Nothing架构的分布式数据库。

TDSQL MYSQL版，即业务获取的是完整的逻辑库表，而后端会将库表均匀的拆分到多个物理分片节点。TDSQL MYSQL版默认部署主备架构，提供容灾、备份、恢复、监控、迁移等全套解决方案，适用于TB或PB级的海量数据库场景。

TDSQL MYSQL版目前单分片最大可支持6TB存储。

数据库架构设计的三种模式

Shared Everthing架构

针对单个主机，完全透明共享CPU、Memory、IO，并行处理能力是最差的。

Shared Disk架构

各个处理单元使用自己的CPU和Memory，但共享磁盘系统。

Shared Nothing架构

无共享架构，每个节点都有属于自己的分区，都有自己的CPU、内存、硬盘，不存在共享资源。每个节点都是独立的，各自处理各自的数据，处理后的结果向上汇总。

水平分表

每个节点都参与计算和数据存储，且每个节点都仅计算和存储一部分数据。因此，无论业务的规模如何增长，仅需要在分布式集群中不断地添加设备，用新设备去应对增长的计算和存储需要即可。

分布式数据库中，根据在建表时设定的分表键，系统将根据不同分表键自动分布数据到不同的物理分片中，但逻辑上仍然是一张完整的表。

正让我想到之前工作中遇到的一种场景，数据太多了，放到一张表里太多了，然后就拆分表，每条数据都有一个字段用来求hash，hash相同的放入到同一张表中，查询的时候，就根据这个hash去对应的表里查询。

数据聚合

数据被插入到不同的表中了，查询的时候就要去各个表中查询，查出来的数据会进行合并，将最终结果返回给用户。

读写分离

读写分离的原理是让主节点Master处理事务性增、改、删操作，让从节点处理查询操作。

数据复制

异步复制

应用发起更新请求，主节点完成相应操作后立即响应应用，主节点向从节点异步复制数据。应用接收到更新成功，其实Slave上还没有同步完数据。

强同步复制

应用发起更新请求，主节点完成操作后向从节点复制数据，从节点接收到数据后向主节点返回成功信息，主节点接到从节点的反馈后再应答给应用。Master向Slave复制数据是同步进行的。这个时候应用收到更新成功，那是真成功了。

半同步复制

应用发起更新请求，Master在执行完更新操作后立即向Slave复制数据，Slave接收到数据并写到relay log中（无需执行）后才向Master返回成功信息，Master必须在接收到Slave的成功信息后再向应用程序返回响应。这个时候应用接收到更新成功，其实数据还没有同步到Slave，需要执行relay log，Slave上才有了更新后数据。

MySQL的relay log，中继日志，是MySQL的主从同步复制过程中的一种日志，用于记录Master上的二进制日志中的事件，然后传输到从库进行重放，以实现从库和主库数据的同步。

当Slave连接到Master时，从库会请求主库的二进制日志中的某个位置开始读取二进制日志，主库会发送从该位置开始的二进制日志到从库，并将这些日志写入到从库的relay log中。然后从库会将relay log中的事件按顺序执行，以保证从库中的数据和主库一致。

当从库完成一个relay log文件的所有事件的执行后，会将该文件标记为完成，然后请求主库的下一个二进制日志文件。同事，MySQL还支持relay log的分发和平衡，可以将relay log文件分发到不同的从库上，提高主从同步的效率和可靠性。    -- 引用资料【2】

参考资料

【1】TDSQL MYSQL官方文档

https://cloud.tencent.com/document/product/557

【2】MySQL的Relay Log日志是干什么的？底层原理是什么？

https://developer.aliyun.com/article/1180928

【3】云监控背后的技术：Shared-nothing Architecture

https://mp.weixin.qq.com/s/KmPpxDXngWP--3Xs72BQng

【4】数据库架构设计的三种模式：share nothing、share everything、share disk

https://www.malaoshi.top/show_1IX4U981uX6K.html