资讯专栏INFORMATION COLUMN

上云采购季！| 2核2G4M爆款云服务器低至59元/年，更有多台、长期优惠，快来选购！

立即前往
首页/文章专栏/TiDB集群在线服务器停机维护主机资源

TiDB集群在线服务器停机维护主机资源

IT那活儿 / 555人阅读
TiDB集群在线服务器停机维护主机资源

点击上方“IT那活儿”公众号，关注后了解更多内容，不管IT什么活儿，干就完了！！！


  
TiDB集群环境随着业务的增长，现每台虚拟服务器（8C+16G）资源已经难以满足业务需求，需对现有的虚拟服务器进行纵向扩容操作，将虚拟服务器资源扩展到16C+32G。
生产环境集群混合部署如下：

由于TiDB-server层是无状态服务，并且有Haproxy进行流量负载均衡，TiKV和PD层有Raft协议的高可用保障，停止单台服务器进行维护对整个集群运行没有太大影响，但是集群会存在有某些SQL访问、在线DDL延迟抖动的情况，总体影响不是太大。延迟抖动主要有以下原因：

  • 存在TiKV层Leader region正好在停机维护的服务器上，从而出现Raft重新选择Leader region，业务已经在运行期间部分SQL在访问中由于找不到原Leader信息会出现Backoff的情况，从而SQL访问伴随有延迟的情况。

  • PD层Leader的转移类似TiKV，TiDB-server层中owner转移需重新选择新owner会对正在执行中DDL有影响。

在线停单台服务器升级CPU、内存的大致维护流程：
  • 在停单台服务器进行维护操作之前梳理DM同步到TiDB的任务，确保同步不失败。
  • 调整max-store-down-time参数(默认30分钟，如果停机时间超过30分钟，建议调大此参数)。
  • Tiup正常停止该节点的TiKV、PD、TiDB实例。
  • 服务器停机。
  • 服务器维护。
  • 服务器启动。
  • 启动该节点的TiKV、PD、TiDB实例。
  • 观察Grafana PD相关的metric信息以及Dashboard访问情况。

  • 应用检查业务使用情况。

停TiKV组件

通常情况下，线上集群对 TiKV 的部署是单机单实例或者单机多实例，在对服务器做临时维护时，需要根据部署情况来进行相应的处理，由于现网为单机单实例只做对应的描述；在实际维护中TiKV节点下线过程中Leader region调度对集群的服务影响很小，并且Leader region调度速度也较快。

注：以下运维命令均为其他环境，实际需根据情况对应进行命令更新。

单机单实例临时关机维护步骤：

  • 修改 max-store-down-time 超过服务器维护时间，默认 30 min，保证在服务器维护期间不发生补副本行为（需要注意维护完成后将参数恢复。）

tiup ctl:v5.0.0 pd -u http://{PDIP}:2379 config set max-store-down-time 60m // 
修改为60分钟，根据实际情况而定

  • 检查是否有 label，确保没有标签（如果存在标签需要多带带分析是否为单机多实例的情况。）

tiup ctl:v5.0.0 pd -u http://{PDIP}:2379 label
  • 检查所有服务器上store的情况，找到该服务器的对应的store id。
tiup ctl:v5.0.0 pd -u http://{PDIP}:2379 store

  • 迁移该服务器上所有 store 的 leader到其他节点。

tiup ctl:v5.0.0 pd -u http://{PDIP}:2379 scheduler add evict-leader-scheduler 2 // 
把 store 2 上的所有 region 的 leader 从 store 2 调度出去

  • 检查 leader 情况：

tiup ctl:v5.0.0 pd -u http://{PDIP}:2379 store 2  // 
检查该服务器所有 tikv 节点上的 leader count，leader count数量为 0 进行下一步，否则等待为0

  • 停止Tikv组件：

tiup cluster stop tidb-test -N {TiKVIP}:20160

停PD组件

通常大多数的线上集群有3 或5个PD节点，如果维护的服务器上有PD 组件，需要具体考虑节点是 leader 还是 follower（以下1 和 2 两部分），关闭 follower 对集群运行没有任何影响，关闭 leader 需要先切换，并在切换时可能存在短暂性能抖动。

1. 当前服务器包括一个 PD follower 节点且集群 PD 总数 >= 3

  • 检查当前待操作 PD 集群节点信息：

tiup ctl:v5.0.0 pd -u http://{PDIP}:2379 member //显示当前所有成员
tiup ctl:v5.0.0 pd -u http://{PDIP}:2379 member leader show //显示当前Leader成员

  • 停止当前待操作 PD follower 节点：

tiup cluster stop tidb-test -N {PDIP}:2379

2. 当前服务器包括一个 PD leader 节点且集群 PD 总数 >= 3

  • 检查当前待操作 PD 集群节点信息：

tiup ctl:v5.0.0 pd -u http://{PDIP}:2379 member //显示当前所有成员

  • 检查当前待操作 PD 节点角色：

tiup ctl:v5.0.0 pd -u http://{PDIP}:2379 member leader show //显示当前leader 的信息

  • 迁移 leader 节点：

tiup ctl:v5.0.0 pd -u http://{PDIP}:2379 member leader transfer pd-id // 将 leader 迁移到指定成员pd-id

  • 检查迁移结果：

tiup ctl:v5.0.0 pd -u http://{PDIP}:2379 member leader show
tiup ctl:v5.0.0 pd -u http://{PDIP}:2379 member //显示当前所有成员，迁移成功进行下一步，否则等待

  • 在待维护服务器上执行停PD节点：

tiup cluster stop tidb-test -N {PDIP}:2379

  • leader 迁回（可选）：

tiup ctl:v5.0.0 pd -u http://{PDIP}:2379 member leader transfer pd-id // 将 leader 迁移到指定成员

停TiDB-server组件

一般情况下，线上使用TiDB会搭配负载均衡使用，在停掉Tidb-server组件之前需确定负载均衡是否需进行对应调整。

1. TiDB-server实例维护

停实例：
tiup cluster stop tidb-test -N {TiDBIP}:4000
2. 风险点
在进行停止TiDB-server 节点时，如果当前节点为 owner 节点（curl http://{TiDBIP}:10080/info ）且正在进行 DDL 变更，直接停止TiDB-server节点会进行新的 owner 选举，DDL变更会变慢。另外如果当前节点非 owner 节点，在停掉之后有 DDL 操作时，每个状态变更时也会去访问该下线的节点，会对集群 DDL 操作有影响，因此尽量避免在临时停止TiDB-server时以及期间进行DDL操作。

在实际生产环境中，TiDB集群经常会和DM（数据同步工具）配合使用，在停单台服务器进行维护操作之前需认真梳理DM同步到TiDB的任务，如果DM工具的目标端是直接连接的TiDB-server，在停服务器维护之前需要对DM工具的Task任务进行调整，停掉DM任务连接的TiDB-server节点会导致同步任务失败。

停grafana、alertmanager、prometheus

中控节点包含多个组件，在停服务器需添加如下组件操作：
  • 停grafana：
tiup cluster stop tidb-test -N {grafanaIP}:3000

  • 停alertmanager：

tiup cluster stop tidb-test -N {alertmanagerIP}:9093
  • 停止prometheus：
tiup cluster stop tidb-test -N {prometheusIP}:9090

关停服务器前检查

  • 检查集群状态，对应的服务器的组件是否都完全停掉。

tiup cluster display tidb-test

停服务器升级CPU和内存并重新启动。

启动服务器后检查集群状态

  • 检查集群状态，是否都正常。

tiup cluster display tidb-test

所有节点都完成后调整参数

  • 修改 max-store-down-time 超过服务器维护时间，默认 30 min，保证在服务器维护期间不发生补副本行为（需要注意维护完成后将参数恢复。）

tiup ctl:v5.0.0 pd -u http://{PDIP}:2379 config set max-store-down-time 30m // 默认30分钟


本文作者：陈 聪（上海新炬王翦团队）

本文来源：“IT那活儿”公众号

GPU云服务器 云服务器 集群维护 查看服务器集群资源 服务器网络资源集群 TiDB 云主机

文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。

转载请注明本文地址：https://www.ucloud.cn/yun/129344.html

相关文章

  • Cloud + TiDB 技术解读

    摘要：作为一个开源的分布式数据库产品，具有多副本强一致性的同时能够根据业务需求非常方便的进行弹性伸缩，并且扩缩容期间对上层业务无感知。另外本身维护了数据多副本，这点和分布式文件系统的多副本是有重复的。 作者：邓栓来源：细说云计算 作为一款定位在 Cloud-native 的数据库，现如今 TiDB 在云整合上已取得了阶段性的进展。日前 Cloud TiDB 产品在 UCloud 平台正式开启...

    JouyPub 评论0 收藏0

  • 贝壳金服 TiDB 在线跨机房迁移实践

    摘要：截至年底，贝壳金服业务已覆盖全国多个城市及地区，为超过万用户提供了金融服务。老机房下线完成则表示数据迁移完成。机房迁移实施过程操作描述配置防火墙，将两个机房所需端口开通。执行下线命令，一次性下线所有旧机房的。跨机房迁移，网络延迟不能高于。 作者介绍 ：李振环，贝壳金服数据基础架构负责人，目前负责数据平台和企业级数据仓库开发。 公司介绍 贝壳金服是专注居住场景的金融科技服务商，起步于2...

    Ashin 评论0 收藏0

  • CNCF案例研究：PingCAP

    摘要：中国论坛提案征集月日截止论坛让用户开发人员从业人员汇聚一堂，面对面进行交流合作。赞助方案出炉多元化奖学金现正接受申请即将首次合体落地中国 PingCAP将其TiDB数据库平台押注在云原生上 showImg(https://segmentfault.com/img/bVbogKp?w=508&h=477); 公司：PingCAP地点：中国北京和加利福尼亚州圣马特奥行业：软件 挑战 流行的...

    h9911 评论0 收藏0

  • CNCF案例研究：PingCAP

    摘要：中国论坛提案征集月日截止论坛让用户开发人员从业人员汇聚一堂，面对面进行交流合作。赞助方案出炉多元化奖学金现正接受申请即将首次合体落地中国 PingCAP将其TiDB数据库平台押注在云原生上 showImg(https://segmentfault.com/img/bVbogKp?w=508&h=477); 公司：PingCAP地点：中国北京和加利福尼亚州圣马特奥行业：软件 挑战 流行的...

    notebin 评论0 收藏0

  • 私有云怎么搭建之智能调度

    摘要：智能调度系统实时监测集群所有计算节点计算存储网络等负载信息，作为虚拟机调度和管理的数据依据。当有新的虚拟资源需要部署时，调度系统会优先选择低负荷节点进行部署，确保整个集群节点的负载。智能调度是 UCloudStack 平台虚拟机资源调度管理的核心，由调度模块负责调度任务的控制和管理，用于决策虚拟机运行在哪一台物理服务器上，同时管理虚拟机状态及迁移计划，保证虚拟机可用性和可靠性。智能调度系统实...

    ernest.wang 评论0 收藏0

发表评论

登陆后可评论

0条评论

IT那活儿

男|高级讲师
我要私信

TA的文章

阅读更多
最新活动
阅读需要支付1元查看
<