《kubernetes》专题

本文介绍了 Kubernetes 上 TiDB 集群常见网络问题以及诊断解决方案。 Pod 之间网络不通 针对 TiDB 集群而言，绝大部分 Pod 间的访问均通过 Pod 的域名（使用 Headless Service 分配）进行，例外的情况是 TiDB Operator 在收集集群信息或下发控制指令时，会通过 PD Service 的 service-name 访问 PD 集群。 当通过日志或

本文介绍 TiDB 集群运行过程中常见异常以及处理办法。 TiKV Store 异常进入 Tombstone 状态 正常情况下，当 TiKV Pod 处于健康状态时（Pod 状态为 Running），对应的 TiKV Store 状态也是健康的（Store 状态为 UP）。但并发进行 TiKV 组件的扩容和缩容可能会导致部分 TiKV Store 异常并进入 Tombstone 状态。此时，可以按

本文介绍了 Kubernetes 上 TiDB 常见部署错误以及处理办法。 Pod 未正常创建 创建集群后，如果 Pod 没有创建，则可以通过以下方式进行诊断： kubectl get tidbclusters -n ${namespace} kubectl describe tidbclusters -n ${namespace} ${cluster_name} kubectl get stat

本文介绍了 Kubernetes 上 TiDB 集群管理常用使用技巧。 诊断模式 当 Pod 处于 CrashLoopBackoff 状态时，Pod 内容器不断退出，导致无法正常使用 kubectl exec 或 tkctl debug，给诊断带来不便。为了解决这个问题，TiDB in Kubernetes 提供了 PD/TiKV/TiDB Pod 诊断模式。在诊断模式下，Pod 内的容器启动后会

本文介绍了如何使用 TiDB Lightning 快速恢复 Kubernetes 上的 TiDB 集群数据。 TiDB Lightning 包含两个组件：tidb-lightning 和 tikv-importer。在 Kubernetes 上，tikv-importer 位于单独的 Helm chart 内，被部署为一个副本数为 1 (replicas=1) 的 StatefulSet；tidb

本文描述了如何销毁 Kubernetes 集群上的 TiDB 集群。 销毁使用 TidbCluster 管理的 TiDB 集群 要销毁使用 TidbCluster 管理的 TiDB 集群，执行以下命令： kubectl delete tc ${cluster_name} -n ${namespace} 如果集群中通过 TidbMonitor 部署了监控，要删除监控组件，可以执行以下命令： kube

故障自动转移是指在 TiDB 集群的某些节点出现故障时，TiDB Operator 会自动添加一个节点，保证 TiDB 集群的高可用，类似于 K8s 的 Deployment 行为。 由于 TiDB Operator 基于 StatefulSet 来管理 Pod，但 StatefulSet 在某些 Pod 发生故障时不会自动创建新节点来替换旧节点，所以，TiDB Operator 扩展了 Stat

TiDB 是高可用数据库，可以在部分数据库节点下线的情况下正常运行，因此，我们可以安全地对底层 Kubernetes 节点进行停机维护。在具体操作时，针对 PD、TiKV 和 TiDB 实例的不同特性，我们需要采取不同的操作策略。 本文档将详细介绍如何对 Kubernetes 节点进行临时或长期的维护操作。 环境准备： kubectl tkctl jq 注意： 长期维护节点前，需要保证 Kuber

在使用 TiDB 集群的过程中，如果你发现某个 Pod 存在内存泄漏等问题，需要对集群进行重启，本文描述了如何优雅滚动重启 TiDB 集群内某个组件的所有 Pod 或通过优雅重启指令来将 TiDB 集群内某个 Pod 优雅下线然后再进行重新启动。 警告： 在生产环境中，未经过优雅重启而手动删除某个 TiDB 集群 Pod 节点是一件极其危险的事情，虽然 StatefulSet 控制器会将 Pod

本文介绍 TiDB 在 Kubernetes 中如何进行水平扩缩容和垂直扩缩容。 水平扩缩容 TiDB 水平扩缩容操作指的是通过增加或减少节点的数量，来达到集群扩缩容的目的。扩缩容 TiDB 集群时，会按照填入的 replicas 值，对 PD、TiKV、TiDB 进行顺序扩缩容操作。扩容操作按照节点编号由小到大增加节点，缩容操作按照节点编号由大到小删除节点。目前 TiDB 集群使用 TidbCl

滚动更新 TiDB 集群时，会按 PD、TiKV、TiDB 的顺序，串行删除 Pod，并创建新版本的 Pod，当新版本的 Pod 正常运行后，再处理下一个 Pod。 滚动升级过程会自动处理 PD、TiKV 的 Leader 迁移与 TiDB 的 DDL Owner 迁移。因此，在多节点的部署拓扑下（最小环境：PD * 3、TiKV * 3、TiDB * 2），滚动更新 TiKV、PD 不会影响业务

基于 Kubernetes 环境部署的 TiDB 集群监控可以大体分为两个部分：对 TiDB 集群本身的监控、对 Kubernetes 集群及 TiDB Operator 的监控。本文将对两者进行简要说明。 TiDB 集群的监控 TiDB 通过 Prometheus 和 Grafana 监控 TiDB 集群。在通过 TiDB Operator 创建新的 TiDB 集群时，可以参考通过 TidbMo

本文档介绍如何在 Kubernetes 上部署 TiDB 集群企业版及相应的企业版工具。TiDB 企业版具有以下特性： 企业级最佳实践 企业级别服务支持 全面加强的安全特性 前置条件 TiDB Operator 部署完成。 部署方法 目前 TiDB Operator 的企业版与社区版部署的差异主要体现在镜像命名上。相比于社区版，企业版的镜像都会多一个 -enterprise 后缀。 spec:

TiCDC 是一款 TiDB 增量数据同步工具，本文介绍如何使用 TiDB Operator 在 Kubernetes 上部署 TiCDC。 前置条件 TiDB Operator 部署完成。 全新部署 TiDB 集群同时部署 TiCDC 参考 在标准 Kubernetes 上部署 TiDB 集群进行部署。 在现有 TiDB 集群上新增 TiCDC 组件 编辑 TidbCluster Custom

本文介绍如何在 Kubernetes 上部署 TiFlash。 前置条件 TiDB Operator 部署完成。 全新部署 TiDB 集群同时部署 TiFlash 参考 在标准 Kubernetes 上部署 TiDB 集群进行部署。 在现有 TiDB 集群上新增 TiFlash 组件 编辑 TidbCluster Custom Resource： kubectl edit tc ${cluster