主动/主动部署之前的准备工作

对于主动/主动部署，必须制定管理冲突的策略，因此在考虑此体系结构之前，请确保了解 复制 和 冲突 的工作方式。

如果需要有关如何对数据进行建模以有效处理冲突的帮助，请转至 IBM Cloud 支持门户网站。

概述

在以下资料中，将创建双向复制。 此配置允许两个数据库以主动/主动拓扑运行。

该配置假定您有两个帐户位于不同的区域中：

• myaccount-dc1.cloudant.com
• myaccount-dc2.cloudant.com

创建这些帐户后，请执行以下步骤:

1. 在帐户中创建一对同级数据库。
2. 设置 API 密钥以用于这两个数据库之间的复制。
3. 授予相应许可权。
4. 设置复制。
5. 测试复制是否按预期工作。
6. 配置应用程序和基础架构，以主动/主动或主动/被动方式使用数据库。

步骤 1. 创建数据库

创建要在每个账户内的 之间复制的数据库。

在此示例中，将创建名为 mydb 的数据库。

本例中数据库使用的名称并不重要、 但使用相同的名称会更清晰。

curl "https://myaccount-dc1.cloudant.com/mydb" -XPUT -u myaccount-dc1
curl "https://myaccount-dc2.cloudant.com/mydb" -XPUT -u myaccount-dc2

步骤 2. 为复制创建应用程序接口密钥

使用 API 密钥 进行连续复制是个好主意。 这样做的优点在于，如果主帐户详细信息更改（例如，在密码重置后），复制可以继续保持不变。

API 密钥不与单个账户绑定。 这意味着可以创建单个 API 密钥、 然后为两个账户授予适当的数据库权限。

例如，以下命令请求帐户 myaccount-dc1 的 API 密钥：

curl -XPOST "https://myaccount-dc1.cloudant.com/_api/v2/api_keys" -u myaccount-dc1

成功的响应类似于以下缩略的示例：

{
  "password": "YPN...Tfi",
  "ok": true,
  "key": "ble...igl"
}

请仔细记下密码。 以后不可能找回密码。

步骤 3. 授予访问许可权

赋予 API 密钥 "准许 来读写两个数据库。

如果还需要复制索引、 分配管理员权限。

使用IBM Cloudant。控制面板、 或查看 授权 信息 了解如何通过编程授予权限。

步骤 4. 设置复制

IBM Cloudant 中的复制始终是单向的: 从一个数据库到另一个数据库。 在两个数据库之间进行双向复制、 需要进行两次复制、 个。

每个账户中都会创建一个复制，该复制使用 之前 创建的 API 密钥。

首先，创建从 myaccount-dc1.cloudant.com/mydb 数据库到 myaccount-dc2.cloudant.com/mydb 数据库的复制。

curl -XPOST "https://myaccount-dc1.cloudant.com/_replicator"
	-u myaccount-dc1
	-H "Content-Type: application/json"
	-d '{
	  "_id": "mydb-myaccount-dc1-to-myaccount-dc2",
	  "source": {
	    "auth": {
	      "basic": {
	        "username": "ble...igl",
	        "password": "YPN...Tfi"
	      }
	    },
	    "url": "https://myaccount-dc1.cloudant.com/mydb"
	  },
	  "target": {
	    "auth": {
	      "basic": {
	        "username": "ble...igl",
	        "password": "YPN...Tfi"
	      }
	    },
	    "url": "https://myaccount-dc2.cloudant.com/mydb"
	  },
	  "continuous": true
}'

接下来，创建从 myaccount-dc2.cloudant.com/mydb 数据库到 myaccount-dc1.cloudant.com/mydb 数据库的复制。

curl -XPOST "https://myaccount-dc2.cloudant.com/_replicator"
	-u myaccount-dc2
	-H "Content-Type: application/json"
	-d '{
	  "_id": "mydb-myaccount-dc2-to-myaccount-dc1",
	  "source": {
	    "auth": {
	      "basic": {
	        "username": "ble...igl",
	        "password": "YPN...Tfi"
	      }
	    },
	    "url": "https://myaccount-dc2.cloudant.com/mydb"
	  },
	  "target": {
	    "auth": {
	      "basic": {
	        "username": "ble...igl",
	        "password": "YPN...Tfi"
	      }
	    },
	    "url": "https://myaccount-dc1.cloudant.com/mydb"
	  },
	  "continuous": true
}'

如果此步骤因 _replicator 数据库不存在而失败，请创建该数据库。

步骤 5. 测试复制

通过在任一数据库中创建、修改和删除文档来测试复制过程。

每次更改数据库后、 检查在另一个数据库中是否也能看到该更改。

步骤 6。 配置应用程序

数据库的设置可保持彼此同步。

接下来，要决定是以主动/主动还是主动/被动方式使用这些数据库。

步骤 7. 后续步骤

• 考虑监视数据库之间的复制。 使用数据来确定配置是否可以进一步优化。
• 考虑如何部署和更新设计文档和索引。 您可能会发现自动执行这些任务会更高效。

在 IBM Cloudant 区域之间进行故障转移

通常情况下 管理区域或数据中心之间故障转移的过程是在应用堆栈的较高位置处理的、 例如，通过配置应用服务器故障切换更改、 或平衡负载。

IBM Cloudant没有为您提供 明确管理区域间的故障转移或路由重定向请求。 造成此约束的部分原因是技术，部分原因在于可能发生这类情况的条件往往是特定于应用程序的。 例如 您可能希望根据自定义性能指标强制进行故障切换。

但是，如果您决定需要管理故障转移的能力，请考虑以下可能的选项:

• 输入您自己的 "IBM Cloudant前面的 HTTP 代理。 将应用程序配置为与代理（而不是 IBM Cloudant 实例）通信。 此配置意味着更改应用程序所使用 IBM Cloudant 实例的任务可以通过修改代理配置（而不是修改应用程序设置）来处理。 许多代理可以根据用户定义的运行状况检查来平衡负载。
• 使用全局负载均衡器 (例如 IBM Cloud® Internet Services ) 来路由到 IBM Cloudant。 此选项需要 CNAME 定义，以根据运行状况检查或等待时间规则来路由到不同的 IBM Cloudant 帐户。

从故障转移恢复

如果无法访问单个 IBM Cloudant 实例，请避免在该实例重新变为可访问后，立即将流量重定向回该实例。 原因是密集型任务（例如，同步来自任何同级的数据库状态，以及确保索引是最新的）需要一些时间才能完成。

有一个监控这些任务的机制很有帮助 以帮助决定数据库何时处于适合为生产流量提供服务的状态。

作为指南，适用的典型检查列表包括：

• 复制
• 索引

如果根据健康测试对请求或故障转移实施重新路由，则可能需要进行相应的检查，以避免过早重新路由到仍在恢复中的服务实例。