Cuando se utilizan cargadores en una topología multimaestro, debe considerar los posibles retos de mantenimiento de la información de revisión y colisión. La cuadrícula de atos mantiene información de revisión sobre los elementos de la cuadrícula de datos de forma que se pueden detectar las colisiones cuando otros fragmentos primarios de la configuración graban entradas en la cuadrícula de datos. Cuando se añaden entradas desde un cargador, esta información de revisión no se incluye y la entrada asume una revisión nueva. Debido a que la revisión de la entrada parece una inserción nueva, se produciría una falta colisión si otro fragmento primario también cambia este estado u obtiene la misma información de un cargador.
Los cambios de la réplica invocan el método get en el cargador con una lista de las claves que no están aún en la cuadrícula de datos pero que se han a cambiar durante la transacción de réplica. Cuando se produce la réplica, estas entradas son entradas de colisión. Cuando se arbitran las colisiones y se aplica la revisión, se llama a una actualización por lotes en el cargador para aplicar los cambios en la base de datos. Todas las correlaciones modificadas en la ventana de revisión se actualizan en la misma transacción.
Considere una topología de dos centros de datos con el centro de datos A y el centro de datos B. Ambos centros de datos tienen bases de datos independientes, pero solo el centro de datos A tiene una cuadrícula de datos en ejecución. Al establecer un enlace entre los cnetros de datos para una configuración multimaestro, las cuadrículas de datos del centro de datos A inician el envío de datos a las nuevas cuadrículas de datos del centro de datos B, lo que causa una colisión con cada entrada. Otro problema importante que se produce es con los datos que se encuentra en la base de datos del centro de datos B pero no en la base de atos del centro de datos A. Estas filas no se llenan ni arbitran, lo que genera incoherencias que no se resuelven.
Con una memoria caché escasa, en primer lugar la aplicación intenta encontrar datos en la cuadrícula de datos. Si los datos no se encuentran en la cuadrícula de datos, se buscan los dato s en la base de atos utilizando el cargador. Se desalojan periodicamente entradas de la cuadrícula de datos para mantener un tamaño pequeño de la memoria caché.
Este tipo de memoria caché puede ser problemático en un escenario de configuración multimaestro porque las entradas de la cuadrícula de datos tienen metadatos de revisión que le ayudarán a detectar qué colisiones se producen y qué lado ha realizado cambios. Cuando los enlaces entre los centros de datos no funcionan, un centro de datos puede actualizar una entrada y a continuación en última instancia actualizar la base de datos e invalidar la entrada en la cuadrícula de datos. Cuando se recupera el enlace, los centros de datos intentan sincronizar las revisiones entre ellos. Sin embargo, debido a que la base de datos se ha actualizado y la entrada de la cuadrícula de datos se ha invalidado, el cambio se pierde desde la perspectiva del centro de datos que se ha interrumpido. Como resultado, los dos lados de la cuadrícula de datos están desincronizados y no son coherentes.
Puede ejecutar el cargador solo en el hub de una topología de hub y radio, lo que mantiene la coherencia de los datos al mismo tiempo que se escala la cuadrícula de datos. Sin embargo, si está considerando el despliegue, tenga en cuenta que los cargadores pueden permitir que la cuadrícula de datos se cargue parcialmente, lo que significa que se ha configurado el desalojador. Si los radios de la configuración son memorias caché escasas pero no tienen cargadores, las faltas de coincidencia de memoria caché no tienen ninguna manera de recuperar los datos de la base de datos. Debido a esta restricción, debe utilizar una topología de memoria caché llenada completamente con una configuración de hub y radio.
La invalidación crea coherencia entre la cuadrícula de datos y la base de datos. Los datos se pueden eliminar de la cuadrícula de datos mediante programación o con desalojo. Al desarrollar la aplicación, debe tener en cuenta que el manejo de revisiones no replica los cambios que se han invalidado, lo que genera incoherencias entre fragmentos primarios.
Los sucesos de invalidación no son cambios de estado de memoria caché y no generan réplica. Los desalojadores configurados se ejecutan independientemente de otros desalojadores de la configuración. Por ejemplo, podría tener un desalojador configurado para un umbral de memoria en un dominio de servicio de catálogo, pero un tipo distinto de desalojador menos agresivo en el servicio de catálogo enlazado. Cuando se eliminan entradas de cuadrícula de datos debido a la política de umbral de memoria, las entradas del otro dominio de servicio de catálogo no resultan afectadas.
Actualizaciones de base de datos e invalidación de cuadrícula de datos
Se producen problemas al actualizar la base de datos directamente en segundo plano al llamar a la invalidación en la cuadrícula de datos para las entradas actualizadas en una configuración multimaestro. Este problema se produce porque la cuadrícula de datos no puede replicar el cambio en otros fragmentos primarios hasta que algún tipo de acceso de memoria caché mueve la entrada a la cuadrícula de datos.
Cuando utiliza una única base de datos con varios fragmentos primarios que se conectan mediante un cargador, se producen conflictos de transacciones. La implementación de cargador debe manejar especialmente estos tipos de escenarios.
Puede configurar bases de datos independientes conectadas a dominios de servicio de catálogo independiente. En esta configuración, el cargador puede enviar cambios de un centro de datos al otro centro de datos.