InfoQ|解读 TiDB：行走在 GKE 上的 NewSQL 开源数据库( 二 )

在被问及是否提供方便迁移的便利工具时，刘寅表示，一方面 MySQL 兼容的数据导入、数据迁移工具都可以无缝的应用于 TiDB 。另一方面，大家熟悉的 MySQL 客户端工具，也可以直接的在 TiDB 上使用。此外，支持数据进来同样也要能出去， TiDB 支持全量导出，可以用 MyDumper 等工具将数据库导出到文件，另外借助 TiDB 的 CDC 机制，把数据库的变化日志写入 Kafka, 再按照用户想要的格式写到下游的数据仓储、数据湖。这样一来，用户完全可以将 TiDB 和其他数据存储和计算生态无缝衔接，组合起来构建业务的底层数据架构。
2GKE 为云上部署和运行 TiDB 提供理想的底座大家可能都有这样一个疑问：像 TiDB 这样一个相对比较复杂的分布式数据库是如何跟云进行结合，在架构上是如何实现云原生设计的？
在 TiDB 的开发初期，容器技术开始被广泛应用，因此 TiDB 早期就定位为云原生数据库并探索如何构建和运行在云环境中。当时选择了 Kubernetes 作为 TiDB 的一个理想底座，但对于 Kubernetes 来讲，很多用户认为 Kubernetes 自身的管理和运维比较复杂，维护成本较高。而使用云托管的 Kubernetes 服务，这个问题就可以得到完美的解决。
“在 GKE（Google Kubernetes Engine）上面，一键就可以创建 Kubernetes 环境，再通过几个命令就可以把 TiDB 部署起来。并且通过 TiDB Operator 的接口，用户可以快速对集群进行扩缩容，滚动升级，实现自动故障转移，以及对集群进行监控、备份。对于运行 TiDB 来讲， GKE 是一个非常理想的底座。 ”
随后刘寅进一步分享了 TiDB 在 GKE 上的一些最佳实践。事实上，在 Kubernetes 上最难的就是管理有状态服务，而像运行 TiDB 这样的分布式数据库更是需要克服很多技术困难。对此 GKE 的四大特性也为 TiDB 在云上运行提供有力的支持：

StatefulSets 的出现使得 GKE 上管理应用状态变的简单；
通过 Operator 模式让升级、滚动重启、扩容等等一系列复杂操作变得统一且标准化， Operator 的模式成功地让复杂分布式基础设施组件具备运行在 GKE 上的能力；
高性能独立存储 (pdssd, pdhdd) ，保证更好的吞吐的同时提供了很好的 IOPS；
[Beta] eBPF for GKE on GCP

作为面向核心业务的数据库， TiDB 在延迟、吞吐等方面有极高的要求，通常需要使用本地盘作为数据库的底层存储介质。然而本地盘在云上并不提供持久化保障，有一定的限制，例如在节点发生故障或者是在替换 VM 镜像时本地盘的数据会抹除。而 TiDB 本身是提供多数据副本，可以支持跨区部署，以此避免单点的磁盘故障对整个集群带来的影响，并进行自治愈恢复。
另一个方面来讲，在 GKE 上面去使用本地盘也有非常大的挑战。本地盘是不能随着 VM 节点来进行漂移， VM 节点的生命周期结束则本地盘的数据也会随之销毁。凭借 Operator 扩展 Kubernetes 的控制器和调度器是一个好方法，当 Operator 发现节点失效时会自动将 Pod 调度到新的节点，并通过 API 操作数据库完成失效节点的下线和新补充节点中的数据副本的恢复。
此外，在云上还可以把 TiDB 的数据副本分布在不同的地域，实现跨可用区部署，这样一来，即使一整个区域发生故障也不会影响到数据库服务的可用性。云提供的 Instance Groups 可以实现节点按需自动伸缩，通过将 GKE 的 HPA（Horizontal Pod Autoscaling) 能力和 Operator 相整合，将数据库和云的弹性能力融合在一起，借助云自身的安全特性提供用户一个可靠、弹性、成本经济的 TiDB 服务。
当被问及 GKE 未来产品路线图值得期待的特性时，吴斌透露出了几点重要信息：首先是 kubernetes 本身就 host 在 Google Cloud 的 GKE 上面，这代表着两个比较关键的信息，一是所有 k8s 原生的功能都将第一时间出现在 GKE 上，二是如果在 GKE 上进行应用整体的开发部署流程，那么它对于原生 k8s 的兼容性也将会非常好。另外，社区开源 k8s 集群在部署管理时受限与例如底层硬件等诸多条件的影响，规模上会有上限。目前在 GKE 上支持集群的大小已经达到了一万五千个节点。并且在原生的 k8s 集群上拉起 pod 的节奏也存在一定限制，在 GKE 上面这个限制取决于集群的大小，尤其对于相对较大规模的集群优势立现。