你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站,请访问 https://docs.azure.cn。
适用于:Azure SQL 数据库
RecoveryManager 类使 ADO.NET 应用程序能够轻松检测并更正分片数据库环境中全局分片映射 (GSM) 与本地分片映射 (LSM) 中的任何不一致性。
GSM 和 LSM 跟踪分片环境中每个数据库的映射。 有时,GSM 和 LSM 之间会发生中断。 在这种情况下,请使用 RecoveryManager
类来检测和修复中断。
该 RecoveryManager
类是 构建可缩放云数据库的一部分。
有关术语定义,请参阅 弹性数据库工具词汇表。 若要了解如何 ShardMapManager
使用分片解决方案管理数据,请参阅 使用分片映射管理器横向扩展数据库。
为何使用恢复管理器
在分片数据库环境中,每个数据库有一个租户,每个服务器有多个数据库。 环境中也可能有多个服务器。 每个数据库映射在分片映射中,以便将调用路由到正确的服务器和数据库。 根据分片键跟踪数据库,将为每个分片分配一系列键值。 例如,分片键可能表示从“D”到“F”的客户名称。所有分片(也称为数据库)的映射及其映射范围都包含在 全局分片映射(GSM)中。 每个数据库还包含分片上所包含范围的映射,称为本地分片映射 (LSM)。 当应用连接到分片时,会在应用中缓存映射用于快速检索。 LSM 用于验证缓存的数据。
GSM 和 LSM 可能会因以下原因而不同步:
- 删除其范围被认为是不再使用的分片,或重命名分片。 删除分片导致 孤立的分片映射。 类似地,重命名的数据库同样可能会造成孤立的分片映射。 根据更改的意图,可能需要删除分片或需要更新分片位置。 若要恢复已删除的数据库,请参阅 从 Azure SQL 数据库中的备份还原数据库。
- 发生异地故障转移事件。 如果要继续,必须有人更新服务器名称和应用程序中分片映射管理器的数据库名称,并更新分片映射中所有分片的分片映射详细信息。 如果有异地故障转移,则应在故障转移工作流中自动执行此类恢复逻辑。 自动化修复操作能够实现顺畅地管理启用异地冗余的数据库,并避免人工操作。 若要了解在数据中心中断时恢复数据库的选项,请参阅 Azure SQL 数据库中的业务连续性 和 灾难恢复指南 - Azure SQL 数据库。
- 分片或
ShardMapManager
数据库还原到较早的时间点。 若要了解如何使用备份进行时间点恢复,请参阅 从 Azure SQL 数据库中的备份还原数据库。
有关 Azure SQL 数据库弹性数据库工具、异地复制和还原的详细信息,请参阅:
在 ShardMapManager 中检索 RecoveryManager
第一步是创建 RecoveryManager
实例。
GetRecoveryManager 方法返回当前 ShardMapManager 实例的恢复管理器。 若要解决分片映射中的任何不一致问题,必须先检索特定分片映射的RecoveryManager
。
ShardMapManager smm = ShardMapManagerFactory.GetSqlShardMapManager(smmConnectionString,
ShardMapManagerLoadPolicy.Lazy);
RecoveryManager rm = smm.GetRecoveryManager();
在此示例中,RecoveryManager
是从 ShardMapManager
初始化的。 包含 ShardMapManager
的 ShardMap
也已初始化。
由于此应用程序代码直接操作分片映射,因此在工厂方法中使用的凭据(在前面的示例 smmConnectionString
中)应该是对连接字符串所引用的 GSM 数据库具有读写权限的凭据。 这些凭据通常与用于为数据相关的路由打开连接的凭据不同。 有关详细信息,请参阅 用于访问弹性数据库客户端库的凭据。
删除分片后从 ShardMap 中删除分片
DetachShard 方法可从分片映射中分离给定的分片,并删除与该分片关联的映射。
- 参数
___location
是要分离的分片的所在位置,具体指服务器名称和数据库名称。 - 参数
shardMapName
是分片映射名称。 仅当多个分片映射由同一分片映射管理器管理时,才需要此参数。 可选。
重要
仅当确定更新映射的范围为空时,才使用此技术。 这些方法不会检查要移动的范围的数据,因此最好在代码中包含检查。
此示例从分片映射删除分片。
rm.DetachShard(s.Location, customerMap);
在删除分片前,分片映射反映了 GSM 中的分片位置。 因为分片已被删除,所以假定这是故意的,并且分片键范围不再使用。 如果不是这种情况,则可以执行时间点还原, 从较早的时间点还原分片。 (在这种情况下,请查看以下部分以检测分片不一致。若要恢复,请参阅 从 Azure SQL 数据库中的备份还原数据库。
由于假设删除数据库是有意而为之的,因此最终的管理清理操作是删除分片映射管理器中分片的条目。 这可以防止应用程序无意中将信息写入非预期范围。
检测映射差异
DetectMappingDifferences 方法可选择并返回其中一个分片映射(本地或全局)做为真实源,并调解两个分片映射(GSM 和 LSM)上的映射。
rm.DetectMappingDifferences(___location, shardMapName);
- 指定
___location
服务器名称和数据库名称。 - 参数
shardMapName
是分片映射名称。 仅当多个分片映射由同一分片映射管理器管理时,才需要此参数。 可选。
解决映射差异
ResolveMappingDifferences 方法可选择其中一个分片映射(本地或全局)做为真实源,并调解两个分片映射(GSM 和 LSM)上的映射。
ResolveMappingDifferences (RecoveryToken, MappingDifferenceResolution.KeepShardMapping);
- 该
RecoveryToken
参数枚举特定分片的 GSM 与 LSM 之间的映射差异。 - MappingDifferenceResolution 枚举 指示用于解决分片映射之间差异的方法。
- 建议在 LSM 包含精确映射时使用
MappingDifferenceResolution.KeepShardMapping
,因此应该使用分片中的映射。 通常情况下,如果发生切换,分片会驻留在新的服务器上。 由于必须先从 GSM 中删除分片(使用RecoveryManager.DetachShard
该方法),因此 GSM 上不再存在映射。 因此,必须使用 LSM 重新建立分片映射。
还原分片后将分片附加到 ShardMap
AttachShard 方法 可将给定的分片附加到分片映射。 然后,它会检测分片映射的任何不一致性,并更新映射以匹配分片还原时间点的分片。 假设对数据库也进行了重命名以反映原始数据库名称(在还原分片之前),因为时间点还原默认为追加时间戳的新数据库。
rm.AttachShard(___location, shardMapName)
- 参数
___location
是所附加分片的服务器名称和数据库名称。 - 参数
shardMapName
是分片映射名称。 仅当多个分片映射由同一分片映射管理器管理时,才需要此参数。 可选。
此示例将分片添加到最近从较早时间点还原的分片映射。 由于已还原分片(也就是 LSM 中的分片映射),因此该分片可能与 GSM 中的分片条目不一致。 在此示例代码之外,分片已还原并已重命名为数据库的原始名称。 由于它已还原,因此假定 LSM 中的映射是受信任的映射。
rm.AttachShard(s.Location, customerMap);
var gs = rm.DetectMappingDifferences(s.Location);
foreach (RecoveryToken g in gs)
{
rm.ResolveMappingDifferences(g, MappingDifferenceResolution.KeepShardMapping);
}
在分片异地故障转移(还原)之后更新分片位置
发生异地故障转移时,使辅助数据库可供写入访问,并成为新的主数据库。 服务器的名称和数据库(具体取决于配置)可能与原始主数据库不同。 因此,必须修复 GSM 和 LSM 中分片的映射条目。 同样,如果数据库还原到不同的名称或位置,或还原到较早的时间点,则可能会造成分片映射中出现不一致性。 分片映射管理器会将打开的连接分发给正确的数据库。 这种分发基于分片映射中的数据以及作为应用程序请求目标的分片键值。 异地故障转移之后,必须使用准确的服务器名称、数据库名称和已恢复数据库的分片映射更新这些信息。
最佳实践
异地故障转移和恢复操作通常由应用程序的云管理员特意使用 Azure SQL 数据库业务连续性功能进行管理。 规划业务连续性需要实施相应的流程、过程和措施,以确保业务运营能够持续进行,而不发生中断。 应该在此工作流中使用 RecoveryManager
类随附的方法,以确保根据采取的恢复操作使 GSM 和 LSM 保持最新状态。 可以执行五个基本步骤来确保在故障转移事件后,GSM 和 LSM 能反映准确的信息。 可将执行这些步骤的应用程序代码集成到现有的工具和工作流中。
- 从 ShardMapManager 中检索
RecoveryManager
。 - 从分片映射中分离旧分片。
- 将新分片附加到分片映射,包括新的分片位置。
- 检测 GSM 和 LSM 之间映射的不一致性。
- 通过信任 LSM,解决 GSM 和 LSM 之间的差异。
此示例执行以下步骤:
从反映故障转移事件之前分片位置的分片映射中删除分片。
将分片附加到反映新分片位置的分片映射(参数
Configuration.SecondaryServer
是新的服务器名称,但是相同的数据库名称)。通过检测每个分片的 GSM 与 LSM 之间映射的差异来检索恢复令牌。
通过信任来自每个分片 LSM 的映射解决不一致性。
var shards = smm.GetShards(); foreach (shard s in shards) { if (s.Location.Server == Configuration.PrimaryServer) { ShardLocation slNew = new ShardLocation(Configuration.SecondaryServer, s.Location.Database); rm.DetachShard(s.Location); rm.AttachShard(slNew); var gs = rm.DetectMappingDifferences(slNew); foreach (RecoveryToken g in gs) { rm.ResolveMappingDifferences(g, MappingDifferenceResolution.KeepShardMapping); } } }
相关内容
尚未使用弹性数据库工具? 请查看入门指南。 如有问题,请在有关 SQL 数据库的 Microsoft Q&A 问题页面上联系我们;如有功能请求,请在 SQL 数据库反馈论坛添加新意见或为现有意见投票。