验证数据中心之间的复制

如何验证您的 API Connect 数据是否复制到热备用数据中心。

在热备用数据中心上无法访问管理和门户网站 UI ，因此无法通过登录到 UI 来检查数据复制是否正常工作。相反，您可以验证热备用管理和门户网站数据库是否与命令行操作同步。

注： OpenShift® 用户：本主题中详细介绍的步骤使用 Kubernetes kubectl 命令。在 OpenShift, 使用等效的 oc 命令来代替它。

验证管理复制

如果管理 CR 检测到管理数据复制问题，那么它会报告警告:

kubectl get mgmt

NAME         READY   STATUS    VERSION      RECONCILED VERSION   MESSAGE                                                                          AGE
management   n/n     Warning   10.0.8.0-0   10.0.8.0-0           Management is ready. HA Status Warning - see HAStatus in CR for details   8m59s

kubectl get mgmt -o yaml

...
status:
  haStatus
    {
      "lastTransitionTime": "2023-03-31T19:47:08Z",
      "message": "Replication not working",
      "reason": "na",
      "status": "True",
      "type": "Warning"
   }

如果该警告仍然存在，请参阅对两个数据中心部署进行故障诊断。

要通过在活动上创建新数据并检查其是否已复制到热备用来验证复制，请执行以下步骤:

登录到 Cloud Manager UI。
创建名为 2dcdrtest的本地用户注册表: 配置本地用户注册表。
在热备用数据中心内运行以下命令，以查询新用户注册表的管理数据库:
```
kubectl exec -n <namespace> `kubectl -n <namespace> get po -l role=primary -o name` -- bash -c "psql -U postgres apim -c \"select name,created_at from user_registry where name = '2dcdrtest'\""
```
期望的输出为:
```
Defaulted container "database" out of: database, set-libpq-certs (init)
   name    |       created_at       
-----------+------------------------
 2dcdrtest | <date and time when step 2 was done>
(1 row)
```
如果返回了 2dcdrtest ，并且具有与执行步骤 2时一致的创建时间，那么复制正在工作。如果未返回，那么表示复制不起作用，或者尚未复制数据。如果返回较旧的创建日期，那么可能是在上次检查后未删除注册表，在这种情况下，将删除注册表并重复此测试。如果复制不起作用，请遵循 2DCDR 故障排除步骤：双数据中心部署故障排除。
返回到 Cloud Manager UI ，然后删除 2dcdrtest 用户注册表。

验证门户网站复制

执行以下步骤以验证门户网站数据库是否正在从活动数据中心复制到热备用数据中心。

在活动数据中心内，标识活动的数据库 pod:
```
kubectl get pods -n <namespace> | grep "<active site name>-db"
```
示例输出如下所示：
```
<portal instance name>-<active site name>-db-0                                                2/2     Running     0          22h
```
其中， <active site name> 是来自活动数据中心上的门户网站 CR 的 siteName 属性。活动数据中心数据库 pod 具有 2 个容器，因此显示状态为 2/2。三个副本部署具有三个数据库 pod ，您可以选择其中任何一个 pod 用于下一步。
在活动数据中心内，运行以下命令:
```
kubectl exec -ti -n <namespace> <active portal db pod> -c db -- bash -ic "dbstatus 2>&1 | grep Last | sed 's/.*committed: \([0-9]*\).*/\1/'"
```
示例输出如下所示：
```
355175
```
其中， <active portal db pod> 是从步骤 1返回的 pod 名称。该命令返回一个数字。
在热备用数据中心内，标识热备用数据库 pod:
```
kubectl get pods -n <namespace> | grep "<warm-standby site name>-db"
```
示例输出如下所示：
```
<portal instance name>-<warm-standby site name>-db-0                                                2/2     Running     0          22h
```
其中， <warm-standby site name> 是热备用数据中心上的门户网站 CR 中的 siteName 属性。热备用数据中心数据库 pod 具有 1 容器，因此显示 1/1 状态。三个副本部署具有三个数据库 pod ，您可以选择其中任何一个 pod 用于下一步。
在 warm-standby 数据中心内，运行以下命令:
```
kubectl exec -ti -n <namespace> <passive portal db pod> -c db -- bash -ic "dbstatus 2>&1 | grep Last | sed 's/.*committed: \([0-9]*\).*/\1/'"
```
示例输出如下所示：
```
355495
```
其中， <passive portal db pod> 是从步骤 3返回的 pod 名称。该命令返回一个数字。
从步骤 2 和 4 返回的数字表示门户网站数据库上次落实的事务号。当活动数据中心落实新事务时，此数目将递增，此更新将复制到热备用数据中心。如果复制正在工作，那么从 warm-standby 数据中心返回的数字应该始终接近从活动数据中心返回的数字。除非您能够同时运行步骤 4 和步骤 2 ，否则它不可能是返回的相同数字。
多次重复步骤 2 和 4 ，以确认热备用号码与活动号码保持一致。如果从暖备用数据中心返回的数字远远落后于或领先于从活动中心返回的数字，则可能存在复制问题，请参阅双数据中心部署故障排除。