使用跨数据中心复制

选择文档版本：

本页面介绍了如何在 Kubernetes 中创建和使用次要数据库集群，以使用跨数据中心复制。

如需从概念上大致了解跨数据中心复制，请参阅跨数据中心复制简介。

准备工作

  • 确认主数据中心和次要数据中心之间建立了可靠的低延迟网络连接，这对于跨数据中心复制的有效运作至关重要。
  • 安装最新版本的 AlloyDB Omni 操作器，以便在主数据中心的 Kubernetes 集群及次要数据中心的 Kubernetes 集群上部署 AlloyDB Omni。AlloyDB Omni 操作器 1.5.0 版及更高版本支持跨数据中心复制。
  • 在主数据中心的 Kubernetes 集群上创建 AlloyDB Omni 数据库集群。
  • 确保主数据库集群中的主数据库服务器和备用数据库服务器具有足够的预写式日志记录 (WAL) 空间，以容纳复制到次要集群所需的 WAL 文件。尚未复制到次要集群的任何数据都会以 WAL 文件的形式存储在主集群中。您可能需要为此用途预留额外的磁盘空间，具体取决于主集群和次要集群之间的连接速度。
  • 请注意以下有关辅助数据库高可用性备用实例（预览版）的信息：如果 AlloyDB Omni 操作器版本和控制平面代理版本为 1.7.0 或更高版本，则辅助数据库集群可以支持高可用性 (HA) 备用实例。

    与主数据库集群上的高可用性备用数据库不同，次要数据库集群上的高可用性备用数据库在次要数据库集群被提升为主数据库之前是异步的。如果在切换期间数据库集群角色发生更改，高可用性备用节点会自动变为同步或异步。

创建次要数据库集群

如需创建 AlloyDB Omni 次要数据库集群并启用从主数据库集群进行复制的功能，请按照以下步骤操作：

  1. 验证是否已在 AlloyDB Omni 主数据库集群上启用外部连接。如果未启用外部连接，请将以下内容添加到数据库集群清单的规范部分：

    ...
spec:
  ...
  allowExternalIncomingTraffic: true

  2. 如需将跨数据中心复制与启用了高可用性 (HA) 的主数据库集群结合使用，请确认主数据库集群上是否已启用 replayReplicationSlotsOnStandbys 字段：

    ...
spec:
  ...
  availability:
    ...
    replayReplicationSlotsOnStandbys: true

    启用此字段以及下一步中所述的 logReplicationSlots 后，系统会将次要数据库集群使用的复制槽同步到所有高可用性备用实例。此配置有助于确保新的高可用性主实例保留在故障切换或切换后尚未被次要数据库集群消耗掉的所有预写式日志记录 (WAL) 文件，从而使次要数据库集群能够在不中断服务的情况下恢复复制数据。

  3. 如需在主数据库集群上启用复制，请将类似于以下内容的清单应用于主数据中心中的 Kubernetes 集群：

    apiVersion: v1
kind: Secret
metadata:
  name: ha-rep-pw-DB_CLUSTER_NAME
  namespace: DB_CLUSTER_NAMESPACE
type: Opaque
data:
  rep-user-pw: "ENCODED_PASSWORD"
---
apiVersion: alloydbomni.dbadmin.goog/v1
kind: Replication
metadata:
  name: REPLICATION_NAME
  namespace: DB_CLUSTER_NAMESPACE
spec:
  dbcluster:
    name: DB_CLUSTER_NAME
  upstream:
    password:
      name: ha-rep-pw-DB_CLUSTER_NAME
    logReplicationSlot: true

    替换以下内容：

    • DB_CLUSTER_NAME：数据库集群的名称，例如 dbc-1。
    • ENCODED_PASSWORD：要用于从次要数据库进行复制的数据库用户的密码（以 base64 字符串编码），例如 Q2hhbmdlTWUxMjM= for ChangeMe123。默认值为 alloydbreplica。
    • REPLICATION_NAME：复制的名称，例如 replication-1。
    • LOG_REPLICATION_SLOT：将复制槽数据记录到 WAL 文件中。如需启用此选项，请将其值设置为 true。默认值为 false。

    建议为启用了高可用性 (HA) 的主数据库集群启用 logReplicationSlot 选项，以确保复制机制在故障切换或切换后仍能继续正常运作。

    等待复制成为准备就绪状态。

  4. 如需获取用于在次要数据库集群上配置复制的上行连接信息，请运行以下命令：

    kubectl get replication REPLICATION_NAME
kubectl get replication REPLICATION_NAME -o json | jq .status.upstream

    示例输出类似于以下内容：

      {
    "host": "35.230.32.36",
    "password": {
      "name": "ha-rep-pw-dbc-1"
    },
    "port": 5432,
    "replicationSlotName": "dbc_1_replication_1",
    "username": "alloydbreplica"
  }
  5. 记下输出，因为您需要在后续步骤中使用它在次要数据库集群上启用复制。
  6. 在次要数据中心的 Kubernetes 集群上创建 AlloyDB Omni 集群，其配置与主数据库集群的配置相同。
  7. 验证是否已在 AlloyDB Omni 次要数据库集群上启用外部连接

  8. 如果未启用外部连接，请将以下内容添加到其清单的规范部分：

    ...
spec:
  ...
  allowExternalIncomingTraffic: true
  9. 如需在次要数据库集群上启用复制，请将类似于以下内容的清单应用于次要数据中心的 Kubernetes 集群： 
    apiVersion: v1
kind: Secret
metadata:
  name: ha-rep-pw-SECONDARY_DB_CLUSTER_NAME
  namespace: SECONDARY_DB_CLUSTER_NAMESPACE
type: Opaque
data:
  rep-user-pw: "ENCODED_PASSWORD"
---
apiVersion: alloydbomni.dbadmin.goog/v1
kind: Replication
metadata:
  name: SECONDARY_REPLICATION_NAME
  namespace: SECONDARY_DB_CLUSTER_NAMESPACE
spec:
  dbcluster:
    name: SECONDARY_DB_CLUSTER_NAME
  downstream:
    host: PRIMARY_HOST
    port: PRIMARY_PORT
    username: alloydbreplica
    password:
      name: ha-rep-pw-SECONDARY_DB_CLUSTER_NAME
    replicationSlotName: PRIMARY_REPLICATION_SLOT
    control: setup

    替换以下内容：

    • SECONDARY_DB_CLUSTER_NAME：次要数据库集群的名称，例如 dbc-2。
    • ENCODED_PASSWORD：要用于从主数据库集群进行复制的数据库用户的密码（以 base64 字符串编码），例如 Q2hhbmdlTWUxMjM= for ChangeMe123。默认值为 alloydbreplica。
    • SECONDARY_REPLICATION_NAME：复制的名称，例如“replication-2”。
    • PRIMARY_HOST：第 4 步输出中的主数据库集群连接端点，次要数据库可以访问该端点以进行复制。
    • PRIMARY_PORT：第 4 步输出中的主数据库集群连接端口，次要数据库可以访问该端口以进行复制。
    • PRIMARY_REPLICATION_SLOT：第 4 步输出中的主数据库集群上的复制槽名称，次要数据库可以将其用于复制。

查看次要数据库集群上的复制

如需查看有关 AlloyDB Omni 次要数据库集群及其复制状态的详细信息，请运行以下命令：

kubectl get dbcluster SECONDARY_DB_CLUSTER_NAME
kubectl get replication SECONDARY_REPLICATION_NAME

当次要数据库集群已成功设置且从主数据库集群进行流式复制时，复制状态为准备就绪且健康状况良好。

提升次要数据库集群

提升次要数据库集群时，您必须先验证次要数据库集群是否已应用从主数据库集群收到的所有事务。

  1. 如需验证集群是否已准备就绪且健康状况良好，请检查次要数据库集群的复制状态。
    kubectl get replication SECONDARY_REPLICATION_NAME
  2. 停止对主数据库集群的所有写入操作。在主数据库集群上执行检查点，然后对主数据库集群运行以下查询，以检查次要数据库的复制延迟时间。确认结果显示最短的延迟时间。
    1. 执行检查点操作，将内存刷新到磁盘。
      psql -h PRIMARY_HOST -U postgres -d postgres -c 'CHECKPOINT;'
    2. 检查复制延迟。最佳延迟时间值为 0。如果延迟时间超过 0，您仍然可以提升次要数据库集群。不过，可能会丢失在主数据库集群中已提交的近期事务。
      psql -h PRIMARY_HOST -U postgres -d postgres -c 'SELECT application_name, pg_wal_lsn_diff(pg_current_wal_lsn(), replay_lsn) AS replay_lag FROM pg_stat_replication;'

  3. 将次要数据库集群提升为主数据库集群，方法是将次要数据库集群复制清单的 control 字段更新为 promote。然后，在次要数据中心的 Kubernetes 集群上应用更新后的复制清单。

    apiVersion: v1
kind: Secret
metadata:
  name: ha-rep-pw-SECONDARY_DB_CLUSTER_NAME
  namespace: SECONDARY_DB_CLUSTER_NAMESPACE
type: Opaque
data:
  rep-user-pw: "ENCODED_PASSWORD"
---
apiVersion: alloydbomni.dbadmin.goog/v1
kind: Replication
metadata:
  name: SECONDARY_REPLICATION_NAME
  namespace: SECONDARY_DB_CLUSTER_NAMESPACE
spec:
  dbcluster:
    name: SECONDARY_DB_CLUSTER_NAME
  downstream:
    host: PRIMARY_HOST
    port: PRIMARY_PORT
    username: alloydbreplica
    password:
      name: ha-rep-pw-SECONDARY_DB_CLUSTER_NAME
    replicationSlotName: PRIMARY_REPLICATION_SLOT
    control: promote

执行切换

在执行切换之前，请验证属于这两个数据中心的主数据库集群和次要数据库集群是否处于在线状态，以及数据库集群是否处于健康状况良好状态。

如需在切换期间强制确保主数据库集群和次要数据库集群的数据一致性，请执行以下步骤，以验证次要数据库集群是否已应用从主数据库集群收到的所有事务：

  1. 检查次要数据库集群的复制状态，验证其是否处于准备就绪且健康状况良好状态。 
    kubectl get replication SECONDARY_REPLICATION_NAME
  2. 停止对主数据库集群的所有写入操作。在主数据库集群上执行检查点，然后对主数据库集群运行以下查询，以检查次要数据库的复制延迟时间。
    1. 执行检查点操作，将内存刷新到磁盘。
      psql -h PRIMARY_HOST -U postgres -d postgres -c 'CHECKPOINT;'
    2. 确认结果显示的延迟时间值为 0。
      psql -h PRIMARY_HOST -U postgres -d postgres -c 'SELECT application_name, pg_wal_lsn_diff(pg_current_wal_lsn(), replay_lsn) AS replay_lag FROM pg_stat_replication;'

  3. 如需将次要集群提升为主要集群，请按以下步骤操作：

    1. 如需将 AlloyDB Omni 次要数据库集群转换为主数据库集群，请在次要数据中心的 Kubernetes 集群上更新其复制清单，如下所示：

      apiVersion: v1
kind: Secret
metadata:
  name: ha-rep-pw-SECONDARY_DB_CLUSTER_NAME
  namespace: SECONDARY_DB_CLUSTER_NAMESPACE
type: Opaque
data:
  rep-user-pw: "ENCODED_PASSWORD"
---
apiVersion: alloydbomni.dbadmin.goog/v1
kind: Replication
metadata:
  name: SECONDARY_REPLICATION_NAME
  namespace: SECONDARY_DB_CLUSTER_NAMESPACE
spec:
  dbcluster:
    name: SECONDARY_DB_CLUSTER_NAME
  upstream:
    password:
      name: ha-rep-pw-SECONDARY_DB_CLUSTER_NAME

      将 SECONDARY_DB_CLUSTER_NAME 替换为次要数据库集群的名称，例如 dbc-2。

      等待复制成为准备就绪状态。

    2. 如需获取用于复制的上行连接信息，请运行以下命令：

      kubectl get replication SECONDARY_REPLICATION_NAME
kubectl get replication SECONDARY_REPLICATION_NAME -o json | jq .status.upstream

      示例输出类似于以下内容：

        {
    "host": "34.23.207.137",
    "password": {
      "name": "ha-rep-pw-dbc-2"
    },
    "port": 5432,
    "replicationSlotName": "dbc_2_replication_2",
    "username": "alloydbreplica"
  }

    3. 如需将 AlloyDB Omni 主数据库集群转换为次要数据库集群，请在主数据中心的 Kubernetes 集群上将其复制清单更新为类似于以下内容：

      apiVersion: v1
kind: Secret
metadata:
  name: ha-rep-pw-DB_CLUSTER_NAME
type: Opaque
data:
  rep-user-pw: "ENCODED_PASSWORD"
---
apiVersion: alloydbomni.dbadmin.goog/v1
kind: Replication
metadata:
  name: REPLICATION_NAME
spec:
  dbcluster:
    name: DB_CLUSTER_NAME
  downstream:
    host: SECONDARY_HOST
    port: SECONDARY_PORT
    username: alloydbreplica
    password:
      name: ha-rep-pw-DB_CLUSTER_NAME
    replicationSlotName: SECONDARY_REPLICATION_SLOT
    control: rewind

      等待复制成为准备就绪且健康状况良好状态。

    4. 如需验证复制状态，请运行以下命令：

      kubectl get replication REPLICATION_NAME

执行非计划灾难恢复

如果您遇到灾难恢复故障切换，请按以下步骤操作：

  1. 如需将 AlloyDB Omni 次要数据库集群转换为主数据库集群，请在次要数据中心的 Kubernetes 集群上更新相应集群的复制清单。如需了解详情，请参阅执行切换中的第 3a 步。
  2. 如需将原来的主数据库集群转换为从新主数据库集群复制数据的辅助数据库集群（角色逆转），请等待原来的主数据库变为可用状态。使用下游复制配置中的 rewind 控制变量来确定转换是否按预期运行。如果您遇到问题，请改用 setup 控制变量。