《集群》专题

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

在 v1.1 及更高版本的 TiDB Operator 中，我们可以通过简单的 CR 文件（即 TidbMonitor）来快速建立对 Kubernetes 集群上的 TiDB 集群的监控。 快速上手 前置条件 已经安装了 Operator v1.1.0 及以上版本，并且已经更新了相关版本的 CRD 文件 已经设置了默认的 storageClass，并保证其有足够的 PV（默认情况下需要 6 个 P

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

在 Kubernetes 集群内访问 TiDB 时，使用 TiDB service 域名 ${cluster_name}-tidb.${namespace} 即可。 若需要在集群外访问，则需将 TiDB 服务端口暴露出去。在 TidbCluster CR 中，通过 spec.tidb.service 字段进行配置： spec: ... tidb: service: ty

本文介绍如何使用 TiUP 的 DM 组件运维 DM 集群。使用 TiUP 部署 DM 的完整步骤可参考使用 TiUP 部署 DM 集群。 注意： 需要确保以下组件间端口可正常连通： 各 DM-master 节点间的 peer_port（默认为 8291）可互相连通。 各 DM-master 节点可连通所有 DM-worker 节点的 port（默认为 8262）。 各 DM-worker 节点可

TiUP 是 TiDB 4.0 版本引入的集群运维工具，TiUP DM 是 TiUP 提供的使用 Golang 编写的集群管理组件，通过 TiUP DM 组件就可以进行日常的运维工作，包括部署、启动、关闭、销毁、扩缩容、升级 DM 集群以及管理 DM 集群参数。 目前 TiUP 可以支持部署 v2.0 及以上版本的 DM。本文将介绍不同集群拓扑的具体部署步骤。 注意： 如果部署机器的操作系统支持

大家知道什么叫做云计算吗？事实上，目前并没有一个确定的定义。然而概括来讲，所谓的云计算，指的就是把你的软件和服务统一部署在数据中心，统一管理，从而实现高伸缩性。 云计算具有以下特性: 虚拟化和自动化 服务器，存储介质，网络等资源都可以随时替换 所有的资源都由云端统一管理 高度的伸缩性以满足业务需求 集中于将服务传递给业务. 云计算的部署方式 从部署方式来说，总共有两类云计算 私有云：数据中心部署在

请确保您已经获取了有效的证书文件。HAproxy所需证书文件格式比较特殊，要求为pem格式，且同时包含证书和与之匹配的私钥,可使用以下命令使之合并： ``` cat demo.crt demo.key > demo.pem ``` 修改 HAproxy 配置文件 配置示例：/etc/haproxy/haproxy.cfg （假设用于健康状态检测的端口为12345） global log 1

在每个 HAproxy 节点上安装和配置 keepalived 来实现浮动 IP 地址。 CentOS 7: yum install keepalived 假设配置了两个 HAproxy 节点：node1、node2 在node1上修改 keepalived 配置文件(/etc/keepalived/keepalived.conf),写入如下内容： ! Configuration File for

在 4.1.0 版本之后，专业版开始支持从 LDAP 或者 AD 导入(同步)群组到 seafile。 工作原理 导入或同步的过程是从 LDAP 服务器上的组映射到 seafile 的内部数据库中的组。这个过程是单向的。 数据库中对组的任何改变都不会回传到 LDAP； 除了“设置成员为组管理员” 之外，数据库中对组的任何更改将被下一个LDAP同步操作覆盖。如果要添加或删除成员则只能在LDAP服务器

一个Kubernetes集群由分布式存储etcd、控制节点controller以及服务节点Node组成。 控制节点主要负责整个集群的管理，比如容器的调度、维护资源的状态、自动扩展以及滚动更新等 服务节点是真正运行容器的主机，负责管理镜像和容器以及cluster内的服务发现和负载均衡 etcd集群保存了整个集群的状态 详细的介绍请参考Kubernetes架构。 集群联邦 集群联邦（Federatio

集群监控的本质是一个聚合功能。 单台机器的监控指标难以反应整个集群的情况，我们需要把整个集群的机器（体现为某个HostGroup下的机器）综合起来看。比如所有机器的qps加和才是整个集群的qps，所有机器的request_fail数量 ÷ 所有机器的request_total数量=整个集群的请求失败率。 我们计算出集群的某个整体指标之后，也会有“查看该指标的历史趋势图” “为该指标配置报警” 这种

kuberntes 系统使用 etcd 存储所有数据，本文档介绍部署一个三节点高可用 etcd 集群的步骤，这三个节点复用 kubernetes master 机器，分别命名为etcd-host0、etcd-host1、etcd-host2： etcd-host0：10.64.3.7 etcd-host1：10.64.3.8 etcd-host2：10.66.3.86 使用的变量 本文档用到的变量

上节课我们和大家学习了怎样用 Promethues 来监控 Kubernetes 集群中的应用，但是对于 Kubernetes 集群本身的监控也是非常重要的，我们需要时时刻刻了解集群的运行状态。 对于集群的监控一般我们需要考虑以下几个方面： Kubernetes 节点的监控：比如节点的 cpu、load、disk、memory 等指标 内部系统组件的状态：比如 kube-scheduler、kub

上一节我们和大家介绍了Prometheus的数据指标是通过一个公开的 HTTP(S) 数据接口获取到的，我们不需要单独安装监控的 agent，只需要暴露一个 metrics 接口，Prometheus 就会定期去拉取数据；对于一些普通的 HTTP 服务，我们完全可以直接重用这个服务，添加一个/metrics接口暴露给 Prometheus；而且获取到的指标数据格式是非常易懂的，不需要太高的学习成本