使用 TiDB 节省时间

去年 11 月，我从在云中扩展这两个解决方案的角度，写了关于开源兼容的云数据库引擎 TiDB 与 MySQL 之间关键差异的文章。在这篇后续文章中，我将更深入地探讨 TiDB 如何简化和精简管理。

如果您有 MySQL 背景，您可能已经习惯于执行许多手动任务，而这些任务在 TiDB 中要么是不需要的，要么是更简单的。

TiDB 的灵感来自于创始人在中国一些最大的互联网公司大规模管理分片 MySQL 的经验。由于大规模运营大型系统的要求是一个关键问题，我将着眼于一些典型的 MySQL 数据库管理员 (DBA) 任务，以及它们如何转化为 TiDB。

在 TiDB 的架构中

• SQL 处理与数据存储分离。SQL 处理 (TiDB) 和存储 (TiKV) 组件可以独立水平扩展。
• PD (Placement Driver) 充当集群管理器并存储元数据。
• 所有组件都原生提供高可用性，PD 和 TiKV 使用 Raft 共识算法。
• 您可以通过 MySQL (TiDB) 或 Spark (TiSpark) 协议访问您的数据。

添加/修复复制从库

tl;dr: 在 TiDB 中，它与 MySQL 中的方式不同。

数据的复制和冗余由 TiKV 自动管理。您也不需要担心创建初始备份来播种副本，因为配置和复制都为您处理。

复制也是基于仲裁的，使用 Raft 共识算法，因此您不必担心异步复制（MySQL 中的默认设置，也是许多用户正在使用的）中出现的与故障相关的不一致问题。

TiDB 确实支持自己的二进制日志，因此它可以用于集群之间的异步复制。

优化慢查询

tl;dr: 在 TiDB 中仍然会发生

对于开发团队引入的慢查询，没有真正的方法可以避免优化。

然而，作为一个缓解因素，如果您需要在优化工作时为数据库的容量增加喘息空间，TiDB 的架构允许您进行水平扩展。

升级和维护

tl;dr: 仍然需要，但通常更容易

由于 TiDB 服务器是无状态的，您可以滚动升级并部署新的 TiDB 服务器。然后，您可以从负载均衡器池中删除旧的 TiDB 服务器，并在连接耗尽后关闭它们。

升级 PD 也非常简单，因为在同一时间只有一个 PD leader 主动响应请求。您可以执行滚动升级，一次升级 PD 的非 leader 对等节点，然后在升级最终的 PD 服务器之前更改 leader。

对于 TiKV，升级稍微复杂一些。如果您想删除一个节点，我建议首先将其设置为它当前作为 leader 的每个区域的 follower。之后，您可以关闭节点而不会影响您的应用程序。如果停机时间很短，TiKV 将通过其区域对等节点从 Raft 日志中恢复。在较长的停机时间内，它将需要重新复制数据。但是，如果您选择使用 Ansible 或 Kubernetes 进行部署，则可以为您管理所有这些。

手动分片

tl;dr: 不需要

手动分片主要是应用程序开发人员的痛点，但作为 DBA，如果分片过于简单或存在热点（许多工作负载都存在热点）等需要重新平衡的问题，您可能不得不介入。

在 TiDB 中，重新分片或重新平衡在后台自动发生。PD 服务器会观察数据区域（TiKV 中键值形式的数据块的术语）何时变得太小、太大或访问过于频繁。

您还可以显式配置 PD 将区域存储在某些 TiKV 服务器上。当与 MySQL 分区结合使用时，效果非常好。

容量规划

tl;dr: 容易得多

MySQL 数据库上的容量规划可能有点困难，因为您需要规划未来两到三年的物理基础设施需求。随着数据增长（以及工作集的变化），这可能是一项艰巨的任务。我不会说它在云中完全消失了，因为更改主服务器的硬件总是很困难的。

TiDB 将数据分成大约 100MiB 的块，并将其分布在 TiKV 服务器之间。由于此增量远小于完整服务器，因此更容易移动和重新分配数据。也可以以较小的增量添加新服务器，这更容易进行规划。

扩展

tl;dr: 容易得多

这与容量规划和分片有关。当我们谈论扩展时，许多人会想到非常大的系统，但这并不是我唯一考虑问题的方式

• 扩展是指能够从小规模开始，而无需在一开始就进行巨额投资，以防它可能变得非常大。
• 扩展也是一个人的问题。如果一个系统需要太多的内部知识才能运行，那么工程组织就很难发展壮大。新员工的入门门槛可能会变得非常高。

因此，通过提供自动分片，TiDB 可以更容易地扩展。

模式更改 (DDL)

tl;dr: 大部分更好

TiDB 中支持的数据定义语言 (DDL) 都是在线的，这意味着它不会阻止对系统的其他读取或写入。它也不会阻止复制流。

这是好消息，但有几个限制需要注意

• TiDB 目前不支持所有 DDL 操作，例如更改主键或某些“更改数据类型”操作。
• TiDB 目前不允许您在同一命令中链接多个 DDL 更改，例如，ALTER TABLE t1 ADD INDEX (x), ADD INDEX (y)。您需要将这些查询分解为单独的 DDL 查询。

这是我们希望在 TiDB 3.0 中改进的领域。

为报表团队创建一次性数据转储

tl;dr: 可能不需要

DBA 讨厌创建一次性数据导出以供另一个团队（可能在分析工具或数据仓库中）使用的手动任务。

当需要在数据集上执行的查询类型是分析型时，通常需要这样做。TiDB 具有混合事务/分析处理 (HTAP) 功能，因此在许多情况下，这些查询应该可以正常工作。如果您的分析团队正在使用 Spark，您也可以使用 TiSpark 连接器，让他们可以直接连接到 TiKV。

这是我们正在使用 TiFlash（一个列式存储加速器）改进的另一个领域。我们还在开发一个插件系统以支持外部身份验证。这将使报表团队更容易管理访问。

结论

在这篇文章中，我研究了一些常见的 MySQL DBA 任务以及它们如何转化为 TiDB。如果您想了解更多信息，请查看我们为 MySQL DBA 设计的 TiDB Academy 课程（它是免费的！）。