GitLab Geo 复制暂停与恢复操作指南

GitLab Geo 复制暂停与恢复操作指南

gitlabhq GitLab CE Mirror | Please open new issues in our issue tracker on GitLab.com 项目地址: https://gitcode.com/gh_mirrors/gi/gitlabhq

前言

在企业级分布式系统管理中，GitLab Geo 提供了跨地域的数据复制功能，确保数据的高可用性和灾难恢复能力。但在某些特定场景下，管理员需要临时暂停复制过程，待操作完成后再恢复复制。本文将深入讲解 GitLab Geo 环境中复制暂停与恢复的操作方法、适用场景及注意事项。

功能概述

GitLab Geo 的复制暂停功能允许管理员临时停止从主站点到辅助站点的数据同步过程。这一功能主要应用于以下场景：

1. 系统升级维护期间
2. 计划内故障转移操作前
3. 数据库架构调整时

前提条件

在使用此功能前，请确认：

• 仅支持使用 Linux 软件包管理的数据库部署
• 不支持外部数据库配置
• 必须在正确的节点上执行命令

执行节点选择

根据不同的数据库架构，执行节点选择如下：

| 架构类型 | 执行节点 | |---------|---------| | 单节点部署 | 该单一节点 | | 独立 PostgreSQL 节点 | PostgreSQL 节点 | | Patroni 集群 | Patroni 备用主节点 |

对于非单节点部署，必须确保 PostgreSQL 或 Patroni 节点的配置文件中包含正确的 geo_node_name 设置，且与应用程序节点一致。

操作命令

暂停复制

在辅助站点上执行以下命令：

gitlab-ctl geo-replication-pause

重要注意事项：

• 暂停后若 PostgreSQL 服务重启（无论是通过 VM 重启还是服务重启），复制将自动恢复
• 暂停期间辅助站点数据会逐渐过时
• 可能导致 Git 获取操作被重定向到主站点
• 可能影响辅助站点 URL 的登录功能

恢复复制

在辅助站点上执行以下命令：

gitlab-ctl geo-replication-resume

特殊场景处理

零停机升级

如果计划在升级期间允许用户在辅助站点上进行操作，则不应暂停复制。因为：

1. 暂停期间辅助站点数据会逐渐过时
2. 越来越多的 Git 获取操作会被代理到主站点
3. 可能导致不可预知的副作用

计划内故障转移

在进行计划内故障转移前暂停复制是推荐做法，但需注意：

1. 确保所有关键数据已同步
2. 记录暂停时间点
3. 故障转移完成后及时恢复复制

最佳实践建议

1. 操作前备份：在执行暂停操作前，建议进行完整系统备份
2. 时间窗口控制：尽量缩短暂停时间，减少数据差异
3. 监控状态：暂停期间密切监控系统状态和日志
4. 用户通知：如可能，提前通知用户可能的服务影响
5. 测试验证：恢复后验证数据一致性

常见问题解答

Q：暂停复制会影响哪些功能？ A：主要影响数据同步，可能导致辅助站点功能受限，如登录重定向、Git操作代理等。

Q：如何确认复制已暂停？ A：可通过监控复制状态命令或检查日志确认。

Q：暂停期间主站点数据会丢失吗？ A：不会，主站点数据不受影响，但辅助站点将不再接收更新。

总结

GitLab Geo 的复制暂停与恢复功能为系统维护提供了灵活性，但需谨慎使用。管理员应充分理解其影响范围，在适当的场景下使用，并遵循最佳实践以确保系统稳定性和数据一致性。

gitlabhq GitLab CE Mirror | Please open new issues in our issue tracker on GitLab.com 项目地址: https://gitcode.com/gh_mirrors/gi/gitlabhq