如果主要区域的存储服务终结点不可用，则客户管理的（计划外）故障转移可以将整个异地冗余存储帐户故障转移到次要区域。 在故障转移期间，原始次要区域将成为新的主要区域。 然后，所有存储服务终结点都会重定向到新的主要区域。 解决存储服务终结点中断问题后，可以再执行一次故障转移操作，故障回复到原始主要区域。
本文介绍在客户管理的（计划外）故障转移和故障回复过程中每个阶段会发生的情况。
提示
若要详细了解计划外故障转移和故障回复过程中的各种冗余状态，请参阅 Azure 存储冗余了解每种冗余状态的定义。
当存储帐户配置为异地冗余存储 (GRS) 或读取访问异地冗余存储 (RA-GRS) 冗余时，数据会在本地冗余存储 (LRS) 主要区域和次要区域内复制三次。 当存储帐户配置为异地区域冗余存储 (GZRS) 或读取访问异地区域冗余存储 (RA-GZRS) 复制时，区域冗余存储 (ZRS) 主要区域中的数据是区域冗余的，并在 LRS 次要区域内复制三次。 如果帐户配置为读取访问 (RA)，则只要该区域的存储服务终结点可用，就可以从次要区域读取数据。
在客户管理的（计划外）故障转移过程中，将切换存储服务终结点的域名系统 (DNS) 条目。 存储帐户的辅助终结点将成为新的主终结点，原始主终结点将会成为新的辅助终结点。 故障转移后，将删除原始主要区域中存储帐户的副本，并且存储帐户将继续在原始次要区域（新的主要区域）内本地复制三次。 此时，存储帐户将变为本地冗余并利用 LRS。
原始和当前冗余配置存储在存储帐户的属性中。 通过此功能，可以在故障回复时返回到原始配置。 有关生成的冗余配置的完整列表，请阅读恢复规划和故障转移。
若要在故障转移后重新获得异地冗余，需要将帐户重新配置为 GRS。 为异地冗余重新配置帐户后，Azure 会立即开始将数据从新的主要区域复制到新的次要区域。 如果将存储帐户配置为对次要区域进行读取访问，则可进行此访问。 然而，从主要区域复制到次要区域可能需要一些时间才能完成。
警告
为异地冗余重新配置帐户后，可能需要花费大量时间才能将新的主要区域中的现有数据完全复制到新的次要区域。
为了避免大量数据丢失，请在故障回复前检查上次同步时间属性的值。 若要评估可能的数据丢失，请比较上次同步时间与数据上次写入新的主要区域时间。
故障回退过程本质上与故障转移过程一样，只是复制配置恢复到其故障转移前的原始状态。
故障回复后，可以重新配置存储帐户，以利用异地冗余。 如果原始主要区域配置为 ZRS，则可以将其配置为 GZRS 或 RA-GZRS。 有关更多选项，请参阅更改存储帐户的复制方式。
若要详细了解如何启动计划外故障转移，请参阅启动帐户故障转移。
警告
计划外故障转移通常涉及一些数据丢失，并且可能存在文件和数据不一致。 务必在启动此类型的故障转移之前了解帐户故障转移对数据的影响。
有关潜在数据丢失和不一致的详细信息，请参阅预期数据丢失和不一致。
本节总结了客户管理的（计划外）故障转移的故障转移过程。
客户管理的（计划外）故障转移之后：
- 次要区域将成为新的主要区域
- 删除原始主要区域中的数据副本
- 存储帐户转换为 LRS
- 地理冗余已丧失
下表汇总了客户管理的（计划外）故障转移和故障回复的每个阶段生成的冗余配置：
| 原始 配置 |
之后 故障转移 |
重新启用后 地理冗余 |
之后 故障回复 |
重新启用后 异地冗余 |
|---|---|---|---|---|
| GRS | LRS | GRS 1 | LRS | GRS 1 |
| GZRS | LRS | GRS 1 | ZRS | GZRS 1 |
1 异地冗余在客户管理的（计划外）故障转移期间丢失，必须手动重新配置。
下图显示了为异地冗余配置的存储帐户的客户管理（非计划）故障转移和故障恢复过程。 GZRS 和 RA-GZRS 的转换细节与 GRS 和 RA-GRS 略有不同。
正常情况下，客户端通过存储服务终结点将数据写入主要区域中的存储帐户 (1)。 然后将数据从主要区域异步复制到次要区域 (2)。 下图显示在主要终结点可用时配置为 GRS 的存储帐户的正常状态：
如果主要存储服务终结点因任何原因而不可用 (1)，则客户端将无法再向存储帐户写入数据。 根据中断的根本原因，复制到次要区域的副本可能不再正常运行 (2)，因此预期会丢失一些数据。 下图展示了主要终结点不可用、但在执行恢复之前的情况：
若要还原对数据的写入访问权限，可以启动故障转移。 Blob、表、队列和文件的存储服务终结点 URI 保持不变，但其 DNS 记录更改为指向次要区域，如下所示：
客户管理的（计划外）故障转移通常需要大约一小时才能完成。
故障转移完成后，原始次要区域将成为新的主要区域 (1)，原始主要区域中存储帐户的副本将被删除 (2)。 存储帐户在新主要区域中配置为 LRS，并且不再具备地理冗余。 用户可以继续将数据写入存储帐户 (3)，如下图所示：
若要继续复制到新的次要区域，请将帐户重新配置为使用异地冗余。
重要
请记住，通过转换本地冗余存储帐户来使用异地冗余会产生成本和时间。 有关详细信息，请参阅故障转移的时间和成本。
将帐户重新配置为利用 GRS 后，Azure 将开始以异步方式将数据复制到新的次要区域 (1)，如下图所示：
在解决导致原始中断的问题之前，对新次要区域的读取访问权限将不再可用。
警告
为异地冗余重新配置帐户后，可能需要花费大量时间才能将新的主要区域中的数据完全复制到新的次要区域。
为了避免大量数据丢失，请在故障回复前检查上次同步时间属性的值。 若要评估可能的数据丢失，请比较上次同步时间与数据上次写入新的主要区域时间。
解决导致原始中断的问题后，可以启动故障回复到原始主要区域。 故障回复过程与先前解释的原始故障转移过程相同。
考虑的要点：
- 使用客户启动的故障转移和故障回复，将不允许数据在故障回复过程中完成复制到次要区域的操作。 因此，请务必在故障回复前检查“上次同步时间”属性的值。
- 将切换存储服务终结点的 DNS 条目。 次要区域中的终结点将成为存储帐户的新主终结点。
故障回复完成后，原始主要区域将重新成为当前主要区域 (1)，原始次要区域中存储帐户的副本将被删除 (2)。 存储帐户在主要区域中配置为本地冗余，并且不再具有异地冗余。 用户可以继续将数据写入存储帐户 (3)，如下图所示：
若要继续复制到新的原始次要区域，请将帐户重新配置为使用异地冗余。
重要
请记住，通过转换本地冗余存储帐户来使用异地冗余会产生成本和时间。 有关详细信息，请参阅故障转移的时间和成本。
将帐户重新配置为 GRS 后，将继续复制到原始次要区域，如下图所示：
