Dentro de una familia de réplicas, se realiza el seguimiento de los cambios para cada réplica.
Esto explica el motivo por el cual la entrada de oplog incluye la identidad de la réplica donde se originó la operación. Por consiguiente, el historial de una familia de réplicas se puede ver como varias pilas de entradas de oplog. Cada pila viene representada por una secuencia lineal de ID de oplog para las operaciones que se originaron en dicha réplica.
El historial de una
base de datos no replicada es una secuencia lineal de operaciones (
Figura 1).
Figura 1. Historial de cambios de una base de datos
La
Figura 2 muestra el estado de dos
réplicas en una familia:
- Se han producido operaciones con los ID de oplog 1–950 en la réplica boston_hub.
- Se han producido operaciones 1–702 en la réplica sanfran_hub.
Figura 2. Estado de una familia
Una réplica tiene datos precisos únicamente sobre sus propias operaciones. Hasta que reciba paquetes de
actualización, la información sobre otras réplicas está obsoleta. Por ejemplo, la réplica
boston_hub registra 950 operaciones locales, pero ha recibido paquetes de actualización para
únicamente 504 operaciones sanfran_hub. Asimismo, la réplica sanfran_hub registra
702 operaciones locales, pero ha recibido paquetes de actualización para únicamente 791 operaciones boston_hub.
La
Figura 3 ilustra este caso de ejemplo, en el que cada réplica
está obsoleta respecto a las operaciones que se originan en la otra réplica.
Figura 3. Réplicas a réplicas
Mostrar una familia de réplicas como conjunto de pilas de oplog, tal como se muestra en la
Figura 3,
permite comprender más fácilmente el proceso de sincronización. Por ejemplo, un paquete de actualización enviado desde
la réplica
boston_hub a la réplica
sanfran_hub consta de incrementos en la pila para la réplica
o
boston_hub (operaciones 792–950). La
Figura 4 muestra los dos incrementos.
Dado que
sanfran_hub conoce su estado, necesita actualizaciones únicamente para operaciones que se originan en las demás réplicas. (En determinadas situaciones de recuperación de errores, debe restablecer los datos de una réplica sobre sus operaciones. )
Figura 4. Actualizaciones entre dos réplicas
Nota: En el momento en el que se importa el paquete sanfran_hub, es posible que se hayan
realizado cambios adicionales en boston_hub. Estos cambios no están incluidos en el paquete de actualización.