在使用了主动读启用（R/E）系统复制场景之后，我们想分享一下我们的经验。官方文档很好，数据与大数据技术，但没有提供很多图表或总体设置、故障转移流程、回切以及如何处理只读查询。和老同事保罗·巴克一起工作。这用于对启用读取功能的活动-活动系统进行简短评估。

系统复制前提条件

2+HANA系统，我们使用HANA 2.00.20（HANA 2 SP2）。相同尺寸系统相同的HANA SID相同的HANA实例#不同的主机名

1。初始景观配置

我们使用了云设备库（CAL）HANA实例，以便快速方便地访问HANA环境。

我们克隆了HANA实例，与GCP和AWS等云提供商合作，这是一种快速复制现有环境的方法。

我们确实遇到了一个问题，即在暂停系统后，我的网络被破坏。经过调查，我们发现CAL有一些聪明的启动脚本，可以自动映射主机名和IP。需要禁用这些脚本以保留对操作系统所做的更改配置。如果您正在试验CAL，则需要修改。

我们现在有两个系统具有相同的SID，但主机名不同，我们现在需要告诉HANA我们有一个新的主机名，这可以通过此命令实现。

要启用系统复制，我们需要将此配置告知主节点和辅助节点。在发出此命令之前，需要停止辅助节点。当重新启动辅助节点时，它将自动与主节点同步所有数据。

为了对应用程序和客户端工具隐藏物理部署，云服务器价格比较，我们可以使用虚拟IP连接我们的服务器环境。为了实现这一点，我们需要为每个HANA节点添加一个辅助网络接口。我们还需要为每个网络接口配置Linux路由表，因为添加第二个接口也会影响第一个接口。

2。DR/HA场景中的故障转移

我们现在可以通过原始IP或新的虚拟IP地址（VIP）访问每个HANA实例。主服务器（第1层）允许任何类型的查询，它还可以将只读查询传递给辅助服务器。我们还可以直接连接到辅助服务器，什么叫云服务，大数据入门，如果我们希望将其用于纯只读分析，我们可以验证当前配置是否符合预期。

在故障转移方案中，主设备可能意外停止，我们可以用kill来模拟这一点。

我们现在告诉次节点（第2层）成为主节点。

第2层现在是主节点，但查询仍被发送到现在已死亡的第1层节点。使用AWS CLI将VIP从第1层节点交换到第2层。该命令是使用AWS控制台生成的，但通过CLI执行可防止错误。这里我们将网络接口与专用IP关联

该过程现已完成，我们已将主HANA节点从第1层交换到第2层。

3。回切到原始配置

回切过程类似，但首先我们需要将旧的主节点（第1层）与脱机时发生的任何更改重新同步。主节点和辅助节点的名称现在非常混乱，因为实际节点已反转，但这些角色仍保留

我们只从单个活动节点开始（第2层）。

在重新启动第1层之前，我们需要告诉它，它现在是一个辅助节点。

当Tier1重新启动时，它现在将同步它未运行期间所做的所有更改。我们还可以验证系统复制配置的状态。

最初，新的辅助节点将不可用。开始运行之前的时间取决于它运行时的更改量离线。重新同步完成后，我们现在和以前一样有2个节点，但是它们的角色是相反的。

为了将第1层提升回主节点，我们需要停止当前的主节点。

我们现在可以告诉第1层它是主节点。它将自动检查第2层是否处于活动状态，然后接管。

需要更新网络以反映部署中的更改。我们将VIP1指向新的主节点，然后VIP2返回已停止的主节点（即将变为次节点）。

我们现在需要告诉Tier2它再次是次节点。

当我们重新启动次节点时，交通大数据，它将与主节点重新同步。

我们完成了此过程，因为我们开始时有两个HANA服务器处于活动配置中。我们可以验证是否按预期配置了所有服务器。