配置读取副本
您可以将 IBM Cloud® Databases for MySQL 部署设置为另一个 Databases for MySQL 部署的读取副本。
读取副本的设置是为了使用异步复制将源实例中的所有数据复制到副本部署中。 顾名思义,读副本支持读事务,可用于平衡既有重写操作又有重读操作的数据库。 如果源数据库实例发生故障,还可以使用读取副本推广来进行数据恢复。 读取副本有一个MySQL数据成员,并按 与源数据库实例 相同的每个成员消耗费率计费。
阅读复制考虑因素
-
读取副本可以与源数据库实例存在于同一区域,也可以存在于不同区域,从而实现跨区域复制数据。
-
读取副本的主要版本必须与其源数据库实例相同。
-
在读取副本上禁用备份。 只对源数据库实例进行备份。
-
Read replication is not supported into or out of EU Cloud-enabled regions (currently
eu-de
). 它在这些区域内得到支持。 -
每个源实例最多只能有五个读取副本。
-
读取副本不参加源数据库实例的选举,也不会自动故障切换到读取副本。 将读取副本升级为完整部署是一项由用户手动启动的任务。
-
读取副本的最小大小为 2 GB 内存和 20 GB 磁盘。 即使源数据库实例部署规模较小,情况也是如此。
-
读取副本不会自动缩放以匹配源数据库实例。 如果存储的数据量超出了分配给部署的磁盘,请在读取副本上扩展磁盘,然后再扩展源数据库实例。 首先扩展读取副本可确保读取副本的空间不会耗尽。 如果是为了性能而不是为了空间来扩展源数据库实例的磁盘,则无需扩展读取副本。
-
复制是异步的,可能会出现复制滞后。 默认情况下,主副本和副本之间不会就一致性问题进行通信。 读取副本有可能远远落后,以至于需要重新同步。 当副本所在区域与其源数据库实例的地理位置相距甚远时,复制滞后可能会更严重。
-
读取副本是一种具有单一数据成员的部署,不具备任何内部高可用性。 在维护期间,容易出现临时中断和停机。 如果您的应用程序依赖于读取副本,请确保有重试失败查询的逻辑,或在多个读取副本上进行负载平衡。
-
Databases for MySQL读取副本在马德里(
eu-es
):目前暂停在马德里eu-es
区域部署读取副本。 我们将尽快提供有关可用性的更新信息。
领导者
在Databases for MySQL部署的_读取副本_选项卡上,在提供任何读取副本之前,中心窗格会指出不存在读取副本,并提供一个创建按钮。

如果某个部署是领导者,并且已经附加了一个读取副本,那么 Replication 窗格中就会显示副本部署列表以及指向每个副本的链接。

调配读取副本
您可以通过单击 Create Read Replica,在领导_Read Replicas_选项卡中提供读取副本。 源实例会自动填入。 读取副本的名称会在 Service Name 字段中自动生成,但您可以自由重命名。 您可以选择要部署它的区域,以及它的初始内存分配。 磁盘大小、版本以及公共或专用端点都会自动配置,以匹配源数据库实例部署的设置。
如果使用 Key Protect,则仅在通过 CLI 和 API 进行调配时支持自带密钥 (BYOK)。 否则,将使用生成的密钥对读取副本进行加密。
通过应用程序接口或 CLI 进行调配
通过 CLI 和 API 提供读取副本的工作方式与 提供标准 Databases for MySQL 部署的工作方式类似。 供应由资源控制器处理,它使用一个参数 {"remote_leader_id": "crn:v1:..."}
来指定要供应的副本的领导者。
例如,通过 CLI 配置读取副本、
ibmcloud resource service-instance-create <replica_name> databases-for-mysql standard <region> \
-p \ '{
"remote_leader_id": "crn:v1:bluemix:public:databases-for-mysql:us-south:a/54e8ffe85dcedf470db5b5ee6ac4a8d8:1b8f53db-fc2d-4e24-8470-f82b15c71819::",
"members_memory_allocation_mb": "2048",
"members_disk_allocation_mb": "10240"
}'
相同的参数用于通过资源控制器 API 提供读取副本。
curl -X POST \
https://resource-controller.cloud.ibm.com/v2/resource_instances \
-H 'Authorization: Bearer <>' \
-H 'Content-Type: application/json' \
-d '{
"name": "<replica_name>",
"target": "<region>",
"resource_group": "<your_resource_group_id>",
"resource_plan_id": "databases-for-mysql-standard",
"remote_leader_id": "crn:v1:bluemix:public:databases-for-mysql:us-south:a/54e8ffe85dcedf470db5b5ee6ac4a8d8:1b8f53db-fc2d-4e24-8470-f82b15c71819::",
"members_memory_allocation_mb": "2048",
"members_disk_allocation_mb": "10240"
}'
对于 CLI 和 API 命令,您必须指定内存和磁盘数量,并牢记内存最小为 2 GB,磁盘最小为 20 GB。 可以选择指定读取副本使用公共端点还是私有端点。 您无法为读取副本指定版本。 版本会自动设置为与源数据库实例部署相同的主要版本。
阅读复制品
在读取副本的 Read Replicas 选项卡上,Replication 窗格包含其名称和区域,以及源数据库实例的名称和区域。 它还有重新同步读取副本和推广副本的按钮。

检查复制状态
复制状态不会被自动监控,您必须监控复制。
您可以使用 mysql
从源数据库实例检查读取副本的复制状态和复制滞后。 使用 mysql
连接到源数据库实例部署 使用 管理员证书。
连接后,运行以下命令:
mysql> SHOW SLAVE STATUS \G
命令状态报告中的一个关键字段将是 Seconds_Behind_Master: _
。 这是复制 SQL 线程处理源二进制日志的滞后秒数。
有关详细信息,请参阅 MySQL's 检查复制状态。
阅读复制用户和权限
-
源数据库实例上的任何用户,即使是在提供读取副本之前就存在的用户,都可以登录读取副本并在读取副本上运行读取操作,其对对象的权限与在源数据库实例上所拥有的权限相同。
-
如果有多个读取副本连接到源数据库实例,则在源数据库上创建的用户也会在所有其他读取副本上创建。
-
在源数据库实例上创建的用户,包括
admin
用户,在升级为独立部署时会在读取副本上持续存在。 推广读副本时,源数据库实例上所有用户的用户和权限都会转移到推广的部署中。 -
所有用户在读取副本上进行的写操作不会被过滤或拒绝,但会在数据库级别失败。
-
在读取副本上创建的读取副本用户能够以
SELECT
权限连接到源数据库实例。
重新同步读取副本
如果需要重新同步读取副本,请单击 Resync Read Replica 按钮。 重新同步是一项破坏性操作,执行重新同步会破坏和重建读取副本中的数据。 在重新同步运行期间,读取副本无法执行任何其他操作或运行任何查询。 查询不会被重新路由到源数据库实例,因此任何到读取副本的连接都会失败,直到它完成重新同步。
重新同步读取副本所需的时间长短不一,但运行时间可能很长。
要通过 CLI 启动重新同步,请使用 cdb read-replica-resync
命令。
ibmcloud cdb read-replica-resync <deployment name>
要通过 API 启动重新同步,请向 /deployments/{id}/remotes/resync
端点发送 POST。
curl -X POST \
https://api.{region}.databases.cloud.ibm.com/v4/ibm/deployments/{id}/remotes/resync \
-H 'Authorization: Bearer <>'
推广阅读副本
读取副本可晋升为独立群集,既可接受写操作,也可接受读操作。 如果源数据库实例发生意外,读取副本可以升级为独立群集,并开始接受应用程序的写入。
要从用户界面推广读取副本,请单击 Promote Read Replica 按钮。
升级后,读取副本将终止与源数据库实例的连接,成为独立的 Databases for MySQL 部署。 部署可以开始接受和运行读写操作,启用备份,并发布自己的管理员用户。 添加一个新的数据成员后,部署就变成了一个有三个数据成员的群集。 这就增加了成本,因为它是按每个成员相同的消耗率计费的,但部署的成员是三个而不是一个。
推广读取副本时,可以跳过通常在推广时进行的初始备份。 跳过初始备份意味着你的副本可以更快地可用,但没有即时备份可用。 推广过程完成后,您就可以开始按需备份。
一旦读取副本晋升为独立部署,就无法将其恢复为读取副本,或让其重新加入源数据库实例。
要通过 CLI 进行升级,请使用 cdb read-replica-promote
命令。
ibmcloud cdb read-replica-promote <deployment name>
要通过 API 进行推广,请向 /deployments/{id}/remotes/promotion
端点发送 POST。
curl -X POST \
https://api.{region}.databases.cloud.ibm.com/v4/ibm/deployments/{id}/remotes/promotion \
-H 'Authorization: Bearer <>' \
-H 'Content-Type: application/json' \
-d '{"promotion": {}}' \
要在升级后跳过初始备份,还需在 JSON 主体中设置 skip_initial_backup
。
curl -X POST \
https://api.{region}.databases.cloud.ibm.com/v4/ibm/deployments/{id}/remotes/promotion \
-H 'Authorization: Bearer <>' \
-H 'Content-Type: application/json' \
-d '{"promotion": {"skip_initial_backup": true}}' \
完成时间
只有当数据库高度可用时,推广配方才会完成。 不过,读/写可用性会在大约 10 分钟后出现,但有一个主要的注意事项:在配方完成之前,数据库不是高度可用的。
读取复制的全部推广时间由数据大小决定,有两种可能的方式:
- 读取副本是单一成员。 升级时,会增加两个成员作为副本。 所需的时间取决于数据的大小。 随着数据库的增长,创建数据库可能需要大量时间。 在两个副本创建完成之前,推广操作不会完成。
- 如果您选择将备份作为推广的一部分,则备份的完成也需要在配方完成前完成。 这同样取决于数据库的大小。
请记住,在推广配方完成之前,高可用性成员是不存在的。 同样,如果您选择了初始备份,则在第二点完成或创建手动备份之前不存在备份。