备份路径和归档路径源端配置案例

在跨机房或跨地域的部署架构下，网络带宽资源通常会更加紧张，因此在配置备份路径和归档路径时，需要考虑路径可访问的 Zone、IDC 或 Region，以便充分利用现有的网络资源，避免跨机房或跨地域的流量产生，提高数据的传输效率。

本节以两地三中心的部署架构为例，为用户提供备份路径和归档路径源端的配置指导。

场景信息

下图为一个两地三中心的部署架构，图中展示了备份所涉及的数据流。OceanBase 数据库的五副本分布在三个机房（IDC）和两个城市，即 2（深圳南山）+2（深圳宝安）+1（杭州）。正常情况下， Leader 副本主要集中在深圳南山的两个 Zone 上，即 PRIMARY_ZONE 的设置为 z1,z2，Root Service（RS）的 Leader 在 Z2 的 obs4 上。

假设，备份介质 NFS 部署在深圳南山的机房（IDC1）内，并且用户配置了可以跨同城的机房访问 NFS，但不允许跨城市访问 NFS。根据用户的配置情况，深圳南山机房（IDC1）和深圳宝安机房（IDC2）的 OBServer 节点均可以访问 NFS，且深圳南山机房（IDC1）的 OBServer 节点访问 NFS 属于同机房访问，而深圳宝安机房（IDC2）的 OBServer 节点访问 NFS 会产生跨机房网络流量。杭州机房的 OBServer 节点无法访问 NFS（因为未挂载 NFS）。

配置备份路径的源端信息

由于数据备份的副本默认是从所有可用的 F 副本中选择，且通常会优先选择 Follower 副本，从上图中可以看出，Root Service（RS）可能会将备份任务调度至 obs10（杭州机房的 OBServer 节点），而 obs10 无法访问 NFS，将会导致备份任务执行失败，因此需要进行备份路径的源端配置，限制可以执行备份任务的节点范围。

该场景下，根据备份不允许跨城市访问 NFS 的规则，可以将备份路径的源端信息配置为 region=Region1、idc=IDC1,IDC2 或者 zone=Z1,Z2,Z3,Z4。配置时，由于数据备份的元信息文件由 RS 节点操作，为了避免因为 RS 节点在源端配置范围外，失去备份路径的访问权限，导致备份任务执行失败，建议将租户的 PRIMARY_ZONE 设置为 ALTER TENANT tenant_name PRIMARY_ZONE='z1,z2'。

假设备份路径为 file:///data/nfs/backup/data，用户租户下，将备份路径的源端信息配置为 region=Region1 的语句如下：

obclient(root@mysql001)[(none)]> ALTER SYSTEM SET DATA_BACKUP_DEST = 'file:///data/nfs/backup/data?region=Region1';

配置成功后，RS 不会再将备份任务转发到 Region2 的节点上，仅转发至 Region1 中可以提供备份服务的节点上，并且 RS 会优先选择 Follower 副本执行备份任务，避免因备份任务增加 Leader 副本的负载而对其他业务造成影响。

同时，根据上述描述可知，当源端配置为 region=Region1、idc=IDC1,IDC2 或者 zone=Z1,Z2,Z3,Z4 后，由于没有优先级之分，可能会有比较多的备份任务会被转发到 IDC2 中的 Follower 副本上（如下图所示），此时备份数据产生的流量为跨机房流量。如果用户的跨机房网络带宽资源较紧张，可以将源端配置修改为 idc=IDC1;IDC2 或者 zone=Z1,Z2;Z3,Z4。

例如，可以通过以下语句将源端配置修改为 idc=IDC1;IDC2。

obclient> ALTER SYSTEM CHANGE EXTERNAL_STORAGE_DEST PATH='file:///data/nfs/backup/data' SET ATTRIBUTE='idc=IDC1;IDC2';

修改后，RS 在选择执行备份任务节点时，IDC1 中的节点具有高优先级，IDC2 中的节点优先级较低。由此可以让备份尽量使用同机房内的网络资源。IDC2 作为备选备份路径可以提升备份任务对于异常情况（例如：IDC1 中的节点宕机）的容忍度，同时可以避免因 RS 被切换到 IDC2 后 RS 失去对备份介质的访问权限而导致备份失败。

配置日志归档路径的源端信息

同样的，对于日志归档而言，该场景下，根据不允许跨城市访问 NFS 的规则，归档路径的源端信息也可以配置为 region=Region1、idc=IDC1;IDC2 或者 zone=Z1,Z2;Z3,Z4。由于日志归档的所有流量均由 Leader 副本负责写入，故对日志归档路径而言，仅有访问权限，没有访问优先级的差异。因此，在配置时，zone=Z1,Z2;Z3,Z4 等价于 zone=Z1,Z2,Z3,Z4；idc=IDC1;IDC2 等价于 idc=IDC1,IDC2。

假设，一用户租户的 PRIMARY_ZONE 为 PRIMARY_ZONE='Z1,Z2,Z3,Z4'，其归档路径为 file:///data/nfs/backup/archive，有以下两个场景：

场景一：初始场景下，网络带宽资源较充足

初始场景下，由于日志归档的网络流量较小，用户租户可通过将归档路径的源端信息配置为 region=Region1 来限制仅 Region1 中的节点可访问归档路径：

obclient(root@mysql001)[(none)]> ALTER SYSTEM SET LOG_ARCHIVE_DEST = 'LOCATION=file:///data/nfs/backup/archive?region=Region1';

配置成功后，可以避免因运维或其他原因将 Leader 副本切换到 Region2，而产生预期外的访问请求（即 Region2 中的 OBServer 节点访问归档路径的请求）。如果系统检测到 Leader 副本在 Region2 上访问归档路径，会发送错误日志（错误码为 -9063），提醒运维人员及时检查：（1）是否存在因为 Locality 名称变更而导致节点失去访问权限；（2）Leader 副本的位置是否被切换到不具有访问权限的节点上，需要及时更新源端配置或手动将 Leader 副本切换到有访问权限的 OBServer 节点上。

场景二：网络带宽资源紧张

随着数据的持续写入，日志归档的网络流量增大，可以将归档路径的源端配置修改为 idc=IDC1，同时租户的 PRIMARY_ZONE 修改为 PRIMARY_ZONE='Z1,Z2'。

obclient(root@mysql001)[(none)]> ALTER SYSTEM CHANGE EXTERNAL_STORAGE_DEST PATH='file:///data/nfs/backup/archive' SET ATTRIBUTE='idc=IDC1';

相关文档

• SET DATA_BACKUP_DEST

• SET LOG_ARCHIVE_DEST

• ALTER/CHANGE/MODIFY EXTERNAL_STORAGE_DEST