Uso de la clase RecoveryManager para solucionar problemas de mapas de particiones

2025-06-13

La clase RecoveryManager proporciona a las aplicaciones ADO.NET la capacidad de detectar y corregir fácilmente las incoherencias entre el mapa de particiones global y el mapa de particiones local en un entorno de base de datos con particiones.

Los mapas de particiones global y local realizan un seguimiento de la asignación de cada base de datos en un entorno con particiones. En ocasiones, se produce una interrupción entre el GSM y el LSM. En ese caso, use la RecoveryManager clase para detectar y reparar la interrupción.

La RecoveryManager clase forma parte de la creación de bases de datos en la nube escalables.

Para definiciones de términos, consulte el Glosario de herramientas de Elastic Database. Para comprender cómo ShardMapManager se usa para administrar datos en una solución fragmentada, vea Escalar bases de datos con el Administrador de Mapas de Fragmentaciones.

¿Por qué usar Recovery Manager?

En un entorno de base de datos particionado, hay un inquilino por base de datos y muchas bases de datos por servidor. También puede haber muchos servidores en el entorno. Cada base de datos se asigna en el mapa de particiones, de forma que las llamadas se puedan enrutar al servidor y a la base de datos correctos. Se realiza un seguimiento de las bases de datos según una clave de particionamiento y se asigna un intervalo de valores de clave a cada partición. Por ejemplo, una clave de particionamiento podría representar los nombres de cliente de "D" a "F". La asignación de todas las particiones (también conocidas como bases de datos) y sus intervalos de asignación se encuentran en el mapa de particiones global (GSM). Cada base de datos también contiene un mapa de los intervalos contenidos en la partición, lo que se conoce como mapa de particiones local (LSM) . Cuando una aplicación se conecta a una partición, la asignación se almacena en caché con la aplicación para una rápida recuperación. El mapa de particiones local se usa para validar los datos almacenados en caché.

El GSM y LSM pueden dejar de sincronizarse por los siguientes motivos:

La eliminación de una partición cuyo intervalo se considera que ya no está en uso o el cambio de nombre de una partición. La eliminación de una partición da como resultado una asignación de particiones huérfana. De igual forma, una base de datos cuyo nombre cambió puede provocar una asignación de particiones huérfanas. En función de la intención del cambio, es posible que sea necesario quitar la partición o actualizar la ubicación de la partición. Para recuperar una base de datos eliminada, consulte Restauración de una base de datos desde una copia de seguridad en Azure SQL Database.
Se produce un evento de conmutación por error geográfica. Para continuar, se debe actualizar el nombre del servidor y el nombre de la base de datos del administrador de mapas de particiones en la aplicación y luego actualizar los detalles de la asignación de particiones de todas las particiones de un mapa de particiones. Si hay una conmutación por error geográfica, se debería automatizar esa lógica de recuperación en el flujo de trabajo de conmutación por error. La automatización de las acciones de recuperación permite una capacidad de administración sin contacto para bases de datos habilitadas geográficamente y evita acciones humanas manuales. Para obtener información sobre las opciones para recuperar una base de datos si hay una interrupción del centro de datos, consulte Continuidad empresarial en Azure SQL Database y guía de recuperación ante desastres: Azure SQL Database.
Una partición o la ShardMapManager base de datos se restauran a un momento dado anterior. Para obtener información sobre la recuperación a un momento dado mediante copias de seguridad, consulte Restauración de una base de datos a partir de una copia de seguridad en Azure SQL Database.

Para más información sobre las herramientas de Elastic Database de Azure SQL Database, la replicación geográfica y la restauración, consulte:

Recuperar RecoveryManager de un ShardMapManager

El primer paso es crear una RecoveryManager instancia. El método GetRecoveryManager devuelve Recovery Manager para la instancia de ShardMapManager actual. Para solucionar cualquier incoherencia en el mapa de particiones, primero debe recuperar el RecoveryManager para el mapa de particiones concreto.

 ShardMapManager smm = ShardMapManagerFactory.GetSqlShardMapManager(smmConnectionString,  
          ShardMapManagerLoadPolicy.Lazy);
          RecoveryManager rm = smm.GetRecoveryManager();

En este ejemplo, RecoveryManager se inicializa a partir de ShardMapManager. El ShardMapManager que contiene un ShardMap también está inicializado.

Dado que este código de aplicación manipula el propio mapa de particiones, las credenciales usadas en el método factory (en el ejemplo anterior, smmConnectionString) deben ser credenciales que tengan permisos de lectura y escritura en la base de datos GSM a la que hace referencia la cadena de conexión. Estas credenciales normalmente son distintas de las credenciales que se usan a fin de abrir conexiones para el enrutamiento dependiente de datos. Para obtener más información, consulte Credenciales usadas para acceder a la biblioteca cliente de Elastic Database.

Quitar una partición de ShardMap después de eliminar una partición

El método DetachShard desasocia la partición determinada del mapa de particiones y elimina las asignaciones asociadas a la partición.

El ___location parámetro es la ubicación de partición, específicamente el nombre del servidor y el nombre de la base de datos, de la partición que se va a desasociar.
El shardMapName parámetro es el nombre del mapa de particiones. Solo es necesario cuando se administran varios mapas de particiones por el mismo administrador de mapas de particiones. Opcional.

Importante

Utilice esta técnica solo si está seguro de que el rango del mapeo actualizado está vacío. Estos métodos no comprueban los datos del intervalo que se mueve, por lo que es mejor incluir comprobaciones en el código.

En este ejemplo se eliminan particiones del mapa de particiones.

rm.DetachShard(s.Location, customerMap);

El mapa de particiones refleja la ubicación de partición en el GSM antes de la eliminación de la partición. Dado que se eliminó el fragmento, se asume que esto fue intencionado, y que el rango de claves de fragmentación ya no está en uso. De lo contrario, puede ejecutar la restauración a un momento dado. Para recuperar la partición de un momento anterior. (En ese caso, revise la sección siguiente para detectar incoherencias de particiones). Para recuperarla, consulte Restauración de una base de datos a partir de una copia de seguridad en Azure SQL Database.

Dado que se supone que la eliminación de la base de datos era intencionada, la acción de limpieza administrativa final es eliminar la entrada a la partición en el administrador de mapa de particiones. Esto impide que la aplicación escriba accidentalmente información en un intervalo que no se espera.

Detectar las diferencias de asignación

El método DetectMappingDifferences selecciona y devuelve uno de los mapas de particiones (local o global) como el origen de datos y reconcilia las asignaciones en ambos mapas de particiones (global y local).

rm.DetectMappingDifferences(___location, shardMapName);

___location especifica el nombre del servidor y el nombre de la base de datos.
El shardMapName parámetro es el nombre del mapa de particiones. Solo es necesario si un mismo administrador de mapas de particiones administra varios mapas de particiones. Opcional.

Resolver diferencias de asignación

El método ResolveMappingDifferences selecciona uno de los mapas de particiones (local o global) como origen de datos y concilia las asignaciones en ambos mapas de particiones (global y local).

ResolveMappingDifferences (RecoveryToken, MappingDifferenceResolution.KeepShardMapping);

El parámetro RecoveryToken enumera las diferencias en las asignaciones entre los mapas de particiones global y local para la partición específica.
La enumeración MappingDifferenceResolution se usa para indicar el método para resolver la diferencia entre las asignaciones de particiones.
Se recomienda MappingDifferenceResolution.KeepShardMapping cuando el mapa de particiones local contenga la asignación precisa y, por tanto, se deba usar la asignación en la partición. Este suele ser el caso si hay una conmutación por error: la partición reside ahora en un nuevo servidor. Como se debe quitar primero la partición del mapa de particiones global (mediante el método RecoveryManager.DetachShard), ya no existe una asignación en el mapa de particiones global. Por lo tanto, debe usarse el mapa de particiones local para volver a establecer la asignación de particiones.

Anexión de una partición al mapa de particiones después de restaurar una partición

El método AttachShard asocia una partición determinada con el mapa de particiones. Detecta entonces cualquier inconsistencia en el mapa de particiones y actualiza las asignaciones para que coincidan con la partición en el punto de la restauración de las particiones. Se supone que la base de datos también se cambia de nombre para reflejar el nombre de la base de datos original (antes de restaurar la partición), ya que la restauración a un momento dado tiene como valor predeterminado una nueva base de datos anexada con la marca de tiempo.

rm.AttachShard(___location, shardMapName)

El ___location parámetro es el nombre del servidor y el nombre de la base de datos, de la partición que se va a adjuntar.
El shardMapName parámetro es el nombre del mapa de particiones. Solo es necesario cuando se administran varios mapas de particiones por el mismo administrador de mapas de particiones. Opcional.

En este ejemplo se agrega una partición al mapa de particiones que se restauró recientemente desde un momento dado anterior. Puesto que la partición (es decir, la asignación de la partición del mapa de particiones local) se restauró, es potencialmente incoherente con la entrada de partición en el mapa de particiones global. Fuera de este código de ejemplo, la partición se restauró y cambió el nombre al nombre original de la base de datos. Como se restauró, se asume que la asignación del mapa de particiones local es la asignación de confianza.

rm.AttachShard(s.Location, customerMap);
var gs = rm.DetectMappingDifferences(s.Location);
   foreach (RecoveryToken g in gs)
    {
    rm.ResolveMappingDifferences(g, MappingDifferenceResolution.KeepShardMapping);
    }

Actualización de las ubicaciones de partición después de una conmutación de error geográfica (restauración) de las particiones

Si se produce una conmutación por error geográfica, a la base de datos secundaria se le da permiso de escritura y se convierte en la nueva base de datos principal. El nombre del servidor y, posiblemente, la base de datos (en función de la configuración), puede ser diferente de la principal original. Por lo tanto, deben corregirse las entradas de asignación para la partición en el mapa de particiones local y global. De igual forma, si la base de datos se restaura en una ubicación o nombre diferente o a un momento anterior en el tiempo, podría provocar inconsistencias en los mapas de particiones. El administrador de mapas de particiones controla la distribución de las conexiones abiertas a la base de datos correcta. La distribución se basa en los datos del mapa de particiones y en el valor de la clave de particionamiento, que es el destino de la solicitud de la aplicación. Después de una conmutación por error geográfica, esta información debe actualizarse con el nombre preciso del servidor, el nombre de la base de datos y la asignación de particiones de la base de datos recuperada.

Procedimientos recomendados

La conmutación por error y la recuperación geográficas son operaciones que normalmente controla un administrador de nube de la aplicación al usar a propósito características de continuidad empresarial de Azure SQL Database. La planeación de la continuidad de negocio requiere procesos, procedimientos y medidas para garantizar que las operaciones empresariales puedan continuar sin interrupción. Deben usarse los métodos disponibles como parte de la clase RecoveryManager dentro de este flujo de trabajo para garantizar que los mapas de particiones local y global se actualizan según la acción de recuperación realizada. Existen cinco pasos básicos para asegurar correctamente que los mapas de particiones local y global reflejan la información precisa después de un evento de conmutación por error. El código de la aplicación para ejecutar estos pasos se puede integrar en el flujo de trabajo y en las herramientas existentes.

Recupere RecoveryManager de ShardMapManager.
Desasocie la partición anterior del mapa de particiones.
Asociar la nueva partición al mapa de particiones, incluida la nueva ubicación de la partición.
Detecte incoherencias en la asignación entre los mapas de particiones global y local.
Resuelva las diferencias entre los mapas de particiones global y local, confiando en el mapa de particiones local.

En este ejemplo se realizan los siguientes pasos:

Quita las particiones del mapa de particiones que reflejan las ubicaciones de particiones anteriores al evento de conmutación por error.
Asocia particiones al mapa de particiones que reflejan las nuevas ubicaciones de particiones (el parámetro Configuration.SecondaryServer es el nuevo nombre del servidor, pero el mismo nombre de base de datos).
Recupera los tokens de recuperación mediante la detección de diferencias de asignación entre los mapas de particiones global y local para cada partición.

Resuelve las incoherencias al confiar en la asignación del mapa de particiones local de cada partición.

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);
         }
     }
 }

¿Aún no ha usado las herramientas de base de datos elástica? Consulte la Guía de introducción. Si tiene alguna pregunta, póngase en contacto con nosotros en la Página de preguntas y respuestas de Microsoft sobre SQL Database y, para efectuar solicitudes de características, agregue nuevas ideas o vote por las ideas existentes en el foro de comentarios sobre SQL Database.