暂停和恢复复制

在某些情况下，例如在升级或计划内故障转移期间，需要暂停主站点和辅助站点之间的复制。

如果您计划在升级期间允许用户在辅助站点上进行活动，则不要为零停机升级暂停复制。暂停期间，辅助站点会变得越来越过时。 一个已知的影响是，越来越多的 Git fetch 操作会被重定向或代理到主站点。可能还存在其他未知的影响。

例如，暂停具有独立 URL 的辅助站点可能会破坏在该辅助站点 URL 上的登录。您会跳转到主站点的根 URL，并且在辅助站点的 URL 上没有新的会话。

暂停和恢复

暂停和恢复复制是通过在辅助站点的特定节点上使用命令行工具完成的。根据您的数据库架构，此操作的目标是 postgresql 或 patroni 服务：

• 如果您在辅助站点上使用单个节点来运行所有服务，则必须在该单个节点上运行命令。
• 如果您的辅助站点上有一个独立的 PostgreSQL 节点，则必须在该独立的 PostgreSQL 节点上运行命令。
• 如果您的辅助站点使用的是 Patroni 集群，则必须在辅助 Patroni 的备用领导者节点上运行这些命令。

如果您没有在辅助站点上使用单个节点来运行所有服务，请确保您的 PostgreSQL 或 Patroni 节点上的 /etc/gitlab/gitlab.rb 文件包含配置行 gitlab_rails['geo_node_name'] = 'node_name'，其中 node_name 与应用程序节点上的 geo_node_name 相同。

暂停操作：（在辅助站点上执行）

另外，请注意，如果在暂停复制后重启 PostgreSQL（无论是通过重启虚拟机还是使用 gitlab-ctl restart postgresql 重启服务），PostgreSQL 都会自动恢复复制，这是您在升级期间或计划内故障转移场景下不希望发生的情况。

gitlab-ctl geo-replication-pause

恢复操作：（在辅助站点上执行）

gitlab-ctl geo-replication-resume