关于跨集群执行物理恢复的疑问

OceanBase 技术问题
#1

Oceanbase版本：4.3.5.5

集群配置：
192.168.0.100
192.168.0.101
192.168.0.102
集群为三zone三副本

归档和备份：
采用兼容S3的OSS备份，已开启归档

关于恢复，现在有两个问题

假设三台服务器全部中了勒索病毒，现在需要原服务原网络重装操作系统系统重新搭建集群，数据恢复的流程什么？

参考文档 执行物理恢复-V4.5.0-OceanBase 数据库文档-分布式数据库使用文档的介绍，我觉得步骤是：
1.搭建集群（不创建业务租户）
2.执行数据恢复（使用原来的兼容S3路径）方式是全量恢复
3.全量恢复后产生的备租户转为主租户 备租户转为主租户-V4.5.0-OceanBase 数据库文档-分布式数据库使用文档
4.对外服务恢复
不知道上面理解的对不对？ 还有以上过程做完之后新的集群开启归档和备份，那么归档存储位置以及备份存储位置还能不能用原来集群的位置（兼容S3存储中相同的路径）

现在原有集群工作正常，但是因为业务原因想要在另外新的服务器搭建新的集群，将数据恢复到3天前的时间点

业务场景，在保证不影响现有集群的情况下，需要查看三天前的数据，新购服务器，还原出指定的时间点，这种应该怎么做？没什么思路

以上疑问

2 个赞
#3

等一个大佬的回答

#4

@论坛小助手

#5

1、看着过程 逻辑上是没有问题的 2、也可以使用物理备份恢复的方式 进行恢复或者使用oms做迁移

#6

关于跨集群执行物理恢复的疑问

1. 原服务原网络重装操作系统系统重新搭建集群的数据恢复流程

您的理解基本正确，以下是详细的步骤：

  1. 搭建集群（不创建业务租户）

    • 按照正常的集群搭建流程，确保新集群的硬件配置和网络环境与原集群一致。
    • 不需要在此阶段创建业务租户。

  2. 执行数据恢复（使用原来的兼容S3路径）

    • 使用 ALTER SYSTEM RESTORE 命令从备份路径恢复数据。确保备份路径和归档路径正确无误。
    • 示例命令：
      ALTER SYSTEM RESTORE dest_tenant_name FROM 'oss://oceanbase-test-bucket/backup/data/?host=***.aliyun-inc.com&access_id=***&access_key=***,oss://oceanbase-test-bucket/backup/archive/?host=***.aliyun-inc.com&access_id=***&access_key=***' WITH 'pool_list=restore_pool&method=full';

  3. 全量恢复后产生的备租户转为主租户

    • 恢复完成后，使用 ALTER SYSTEM ACTIVATE STANDBY TENANT 命令将备租户转为主租户。
    • 示例命令：
      ALTER SYSTEM ACTIVATE STANDBY TENANT dest_tenant_name;

  4. 对外服务恢复

    • 确保所有配置和服务正常后，重新对外提供服务。

2. 新服务器搭建新集群并恢复3天前的数据

为了在不影响现有集群的情况下查看三天前的数据，您可以按照以下步骤操作：

  1. 搭建新集群（不创建业务租户）

    • 按照正常的集群搭建流程，确保新集群的硬件配置和网络环境符合要求。
    • 不需要在此阶段创建业务租户。

  2. 执行数据恢复（恢复到指定时间点）

    • 使用 ALTER SYSTEM RESTORE 命令从备份路径恢复数据，指定恢复到3天前的时间点。
    • 示例命令：
      ALTER SYSTEM RESTORE dest_tenant_name FROM 'oss://oceanbase-test-bucket/backup/data/?host=***.aliyun-inc.com&access_id=***&access_key=***,oss://oceanbase-test-bucket/backup/archive/?host=***.aliyun-inc.com&access_id=***&access_key=***' UNTIL TIME='2023-10-01 00:00:00' WITH 'pool_list=restore_pool&method=full';

  3. 全量恢复后产生的备租户转为主租户

    • 恢复完成后，使用 ALTER SYSTEM ACTIVATE STANDBY TENANT 命令将备租户转为主租户。
    • 示例命令：
      ALTER SYSTEM ACTIVATE STANDBY TENANT dest_tenant_name;

  4. 对外服务恢复

    • 确保所有配置和服务正常后，重新对外提供服务。

归档存储位置及备份存储位置

关于新的集群是否可以使用原来集群的归档和备份存储位置：

  • 归档存储位置

    • 新集群可以使用原来集群的归档存储位置。只要确保新的集群能够访问到相同的 S3 兼容存储路径即可。
    • 示例配置：
      SET GLOBAL log_archive_dest = 'oss://oceanbase-test-bucket/backup/archive/?host=***.aliyun-inc.com&access_id=***&access_key=***';

  • 备份存储位置

    • 新集群可以使用原来集群的备份存储位置。同样，确保新的集群能够访问到相同的 S3 兼容存储路径。
    • 示例配置：
      SET GLOBAL backup_data_dest = 'oss://oceanbase-test-bucket/backup/data/?host=***.aliyun-inc.com&access_id=***&access_key=***';

总结

  1. 搭建新集群并恢复数据的流程是正确的。
  2. 新集群可以使用原来集群的归档和备份存储位置，只需确保新集群能够访问到相同的 S3 兼容存储路径。

希望以上解答对您有所帮助。如有其他问题，请随时联系。

具体信息可参考以下文档:

  1. 监测历史会话性能
#7

根据您的问题，以下是对 OceanBase 数据库跨集群物理恢复流程的解答：

情景一：三台服务器全部中了勒索病毒，需要原服务原网络重装操作系统系统重新搭建集群

  1. 搭建新集群：重新安装操作系统并部署新的 OceanBase 集群，但不立即创建业务租户。
  2. 执行数据恢复：使用全量恢复方式从原来的兼容 S3 路径恢复数据。命令示例如下：
    ALTER SYSTEM RESTORE <dest_tenant_name> FROM '<backup_uri>' UNTIL TIME='<timestamp>' WITH 'pool_list=<pool_list>&method=full';
  3. 备租户转为主租户：恢复完成后，将备租户转为主租户，使其对外提供服务。命令如下：
    ALTER SYSTEM ACTIVATE STANDBY TENANT <dest_tenant_name>;
  4. 恢复服务：新集群开始对外提供服务。
  5. 重新配置归档和备份：新集群可以使用原有的归档和备份路径，确保新的归档和备份数据继续存储在相同的路径下。

情景二：在现有集群正常工作的情况下，新购服务器搭建新的集群，恢复到3天前的时间点

  1. 搭建新集群：在新购服务器上安装操作系统并部署新的 OceanBase 集群，不立即创建业务租户。
  2. 执行数据恢复：使用全量恢复方式从现有的备份路径恢复到3天前的时间点。命令示例如下：
    ALTER SYSTEM RESTORE <dest_tenant_name> FROM '<backup_uri>' UNTIL TIME='<3_days_ago_timestamp>' WITH 'pool_list=<pool_list>&method=full';
  3. 备租户转为主租户：恢复完成后，将备租户转为主租户，使其对外提供服务。命令如下：
    ALTER SYSTEM ACTIVATE STANDBY TENANT <dest_tenant_name>;
  4. 验证数据：确保新集群中的数据与3天前的时间点一致。
  5. 重新配置归档和备份：新集群可以使用原有的归档和备份路径，确保新的归档和备份数据继续存储在相同的路径下。

注意事项

  • 备份路径：确保备份路径和归档路径在新集群中仍然有效。
  • 恢复权限：确保执行恢复操作的用户具有足够的权限。
  • 网络连通性：确保新集群能够访问备份路径和归档路径。
  • 资源池配置：合理配置资源池，确保新集群的资源分配符合业务需求。

希望上述步骤对您有所帮助。

具体信息可参考以下文档:

  1. LOAD DATA
  2. 按表恢复相关参数介绍
  3. CREATE PROCEDURE
  4. 使用 obd 进行运维
#8

论坛小助手果然很强大，但是对于第二个情景的解决方案有明显的缺陷。这个场景下最核心的是不能影响原有集群，说白了就是个基于正式集群临时整出来一个临时集群用于数据核查等。这个时候第五步重新配置归档和备份还用原来正式集群使用的路径肯定有问题。两个完全不同的集群使用同一个路径进行归档和备份。不会错乱么？