Servicio forzado (con posible pérdida de datos)
La creación de reflejo de la base de datos permite forzar el servicio (con posible pérdida de datos) como método de recuperación de desastres para permitir el uso de un servidor reflejado como servidor en espera activa. Sólo se puede forzar el servicio si el servidor principal se desconecta del servidor reflejado en una sesión de creación de reflejo. Puesto que forzar el servicio puede suponer una posible pérdida de datos, se debe hacer con precaución y moderación.
La compatibilidad con el servicio forzado depende del modo de funcionamiento y del estado de la sesión, según se indica a continuación:
Generalmente, el modo de alto rendimiento permite forzar el servicio siempre que el servidor principal esté desconectado. Sin embargo, aunque es innecesario, puede existir un testigo para una sesión en modo de alto rendimiento. En este caso, forzar el servicio requiere que el servidor reflejado y el testigo estén conectados entre sí.
El modo de alta seguridad sin conmutación automática por error permite forzar el servicio siempre que el servidor principal esté desconectado.
El modo de alta seguridad con conmutación automática por error permite forzar el servicio siempre que el servidor reflejado y el testigo estén conectados entre sí y ninguno de ellos esté conectado al servidor principal (siempre que el servidor reflejado no estuviera en el proceso para revertir la base de datos reflejada cuando se conectó por última vez al principal).
Se recomienza que el servicio sólo se fuerce si es necesario restaurarlo en la base de datos inmediatamente y es aceptable el riesgo de perder algunos datos. El efecto de forzar el servicio es similar a quitar la creación de reflejo, excepto en que al forzar el servicio se facilita volver a sincronizar las bases de datos cuando se reanuda la creación de reflejo, con el riesgo de la posible pérdida de datos. Al forzar el servicio se inicia una transición sin problemas de la función principal a la base de datos reflejada. El servidor reflejado asume la función de servidor principal y ofrece su copia de la base de datos a los clientes inmediatamente. La nueva base de datos principal se ejecuta sin reflejar (es decir, se ejecuta expuesta).
.gif "Nota importante") Importante |
|---|
Si el servidor principal simplemente se desconecta de la sesión de creación de reflejo de la base de datos y sigue ejecutándose, algunos clientes podrían continuar teniendo acceso a la base de datos principal original. Antes de forzar el servicio, es importante impedir que los clientes tengan acceso al servidor principal original. De lo contrario, una vez forzado el servicio, la base de datos principal original y la base de datos principal actual podrían actualizarse independientemente. |
Caso típico de servicio forzado
En la figura siguiente se ilustra un caso típico de servicio forzado (con posible pérdida de datos).
.gif "Forzar servicio con posible pérdida de datos")
En la figura, el servidor principal original, Partner_A, deja de estar disponible para el servidor reflejado, Partner_B, lo que ocasiona la desconexión de la base de datos reflejada. Después de asegurarse de que el servidor Partner_A no está disponible para los clientes, el administrador de la base de datos fuerza el servicio, con posible pérdida de datos, en el servidor Partner_B. Partner_B se convierte en el servidor principal y se ejecuta con la base de datos expuesta (sin reflejo). En este momento, los clientes pueden volver a conectarse a Partner_B.
Cuando Partner_A está disponible, se vuelve a conectar al nuevo servidor principal, con lo que se vuelve a unir a la sesión y asume la función de reflejo. La sesión de creación de reflejo se suspende inmediatamente, sin haber sincronizado la nueva base de datos reflejada. Al suspender la sesión, se permite al administrador de la base de datos decidir si reanudarla o, en casos extremos, quitar la creación de reflejo e intentar salvar los datos desde la antigua base de datos principal. En este caso, el administrador de la base de datos elige reanudar la creación de reflejo. En este momento, Partner_A asume la función de servidor reflejado y revierte la base de datos principal anterior hasta el momento en que se produjo la última transacción que se sincronizó correctamente; si alguna transacción confirmada no se grabó en el disco en el servidor reflejado antes de forzar el servicio, se pierde. Partner_A revierte entonces la nueva base de datos reflejada y aplica los cambios establecidos en la nueva base de datos principal desde que el anterior servidor reflejado se convirtió en el nuevo servidor principal.
[!NOTA]
Si bien el modo de alto rendimiento no necesita ningún testigo, si se configura uno, sólo es posible forzar el servicio si el testigo está actualmente conectado al servidor reflejado.
Riesgos de forzar el servicio
Es esencial tener en cuenta que si se fuerza el servicio se pueden perder datos. La pérdida de datos es posible porque el servidor reflejado no se puede comunicar con el principal y, por lo tanto, no puede garantizar que las dos bases de datos estén sincronizadas. Al forzar el servicio se inicia una nueva bifurcación de recuperación. Puesto que la base de datos principal original y la base de datos reflejada están en bifurcaciones de recuperación diferentes, cada base de datos contiene ahora datos que no contiene la otra: la base de datos principal original contiene los cambios que aún no hayan sido enviados desde su cola de envío a la base de datos reflejada anterior (el registro sin enviar); la base de datos reflejada anterior contiene los cambios que se hayan producido después de forzar el servicio.
[!NOTA]
Para obtener más información acerca de las bifurcaciones de recuperación, vea Rutas de recuperación.
Si el servicio se fuerza debido a que el servidor principal no funcionó, la posible pérdida de datos depende de si no se envió ningún registro de transacciones al servidor reflejado antes del problema. En el modo de alta seguridad, esto sólo es posible hasta que se sincroniza la base de datos reflejada. En el modo de alto rendimiento, la acumulación del registro sin enviar siempre es una posibilidad.
Las implicaciones derivadas de forzar el servicio dependen en parte de si la sesión tiene un testigo:
En ausencia de un testigo, el servicio se puede forzar si los asociados se desconectan, por ejemplo, debido a que se interrumpa su conexión de red. Si el servidor principal original se sigue ejecutando, ambos asociados tienen la función principal. Los clientes que se conecten al nuevo servidor principal tendrán acceso a la versión actual de la base de datos, mientras que los clientes que se conecten al servidor principal original tendrán acceso a la base de datos principal original. Esta situación aumenta la posibilidad de perder los datos. Si se permite a los asociados volver a conectarse, el servidor principal original asume la función de servidor reflejado y cambia el estado de su base de datos a "recuperando" antes de que se suspenda la creación de reflejo. Si la sesión se reanuda, se pierden las transacciones de la base de datos principal original cuyo registro estuviera en la cola de envío en el momento de la desconexión más reciente. Además, también se pierde cualquier transacción que se produzca después de forzar el servicio.
En presencia de un testigo, si el servidor reflejado se desconecta tanto del servidor principal como del testigo, siempre que los dos últimos permanezcan conectados entre sí, el principal se ejecuta expuesto. Si el servidor principal se desconecta entonces del testigo, deja de atender a la base de datos. Después, si el servidor reflejado vuelve a conectarse al testigo, es posible forzar el servicio. Si se fuerza el servicio, todos los cambios realizados mientras el servidor principal original se ejecutaba expuesto se perderán si éste vuelve a conectarse.
Para obtener más información, vea "Administrar la potencial pérdida de datos", más adelante en este tema.
Administrar la potencial pérdida de datos
Después de forzar el servicio, una vez que el servidor principal anterior está disponible, siempre que su base de datos no esté dañada, se puede intentar administrar la posible pérdida de datos. El enfoque disponible para administrar la posible pérdida de datos depende de si el servidor principal original se ha vuelto a conectar a su asociado o se ha vuelto a unir a la sesión de creación de reflejo. Suponiendo que el servidor principal original pueda tener acceso a la nueva instancia principal, la reconexión se produce de forma automática y transparente.
El servidor principal original se ha vuelto a conectar
Generalmente, después de un problema, cuando el servidor principal original se reinicia, se vuelve a conectar rápidamente a su asociado. Al reconectarse, el servidor principal original se convierte en el servidor reflejado. Su base de datos se convierte en la base de datos reflejada y entra en el estado de recuperación antes de suspenderse la sesión. La base de datos reflejada no se revertirá a menos que se reanude la creación de reflejo.
Sin embargo, la recuperación de la base de datos es inaccesible; por lo tanto, no se puede inspeccionar para evaluar qué datos se perderían si se reanudara la creación de reflejo. Por lo tanto, la decisión de si reanudar o quitar el reflejo depende de si se está dispuesto a aceptar de algún modo la pérdida de datos.
Si la pérdida de datos sería inaceptable, debe quitar la creación de reflejo para salvarlos.
Quitar la creación de reflejo permitiría al administrador de la base de datos recuperar la base de datos principal original e intentar recuperar los datos que se hubieran perdido. Sin embargo, cuando la base de datos reflejada anterior vuelva a ponerse en línea, los asociados anteriores atenderán a bases de datos diferentes con el mismo nombre. El administrador de la base de datos tiene que hacer que una de las bases de datos esté inaccesible para los clientes con el fin de evitar una mayor diferencia de la base de datos e impedir problemas de conmutación por error del cliente.
Si la pérdida de datos fuera aceptable, podría reanudar la creación de reflejo.
Al reanudar la creación de reflejo, la nueva base de datos reflejada se revierte como primer paso para sincronizarla. Si alguna entrada del registro estuviera esperando en la cola de envío en el momento del problema, se perderían las transacciones correspondientes, incluso si se hubieran confirmado.
El servidor principal original no se ha vuelto a conectar
Si puede impedir temporalmente que el servidor principal original se vuelva a conectar a través de la red al nuevo servidor principal, puede inspeccionar la base de datos principal original para evaluar qué datos se perderían si se reanudara la creación de reflejo.
Si la posible pérdida de datos es aceptable
Permita que el servidor principal original se vuelva a conectar a su asociado. La reconexión ocasiona la suspensión de la creación de reflejo. Para continuar con la creación de reflejo, simplemente reanude la sesión. El servidor principal anterior asume la función de servidor reflejado. El nuevo servidor reflejado descarta la bifurcación de recuperación original, con lo que se pierden las transacciones que no se hubieran enviado al servidor reflejado anterior o que éste no hubiera recibido.
Si la pérdida de datos es inaceptable
Si la base de datos principal original contiene datos esenciales que se perderían si se reanudara la sesión, puede quitar la creación de reflejo para preservar los datos del servidor principal original. Recomendamos que intente realizar una copia de seguridad del registro después del error de la base de datos principal en este momento. Luego puede actualizar la base de datos principal actual (la base de datos reflejada anterior) exportando los datos que desea salvar de la base de datos principal original e importándolos a la base de datos principal actual. Se recomienda realizar una copia de seguridad completa de la base de datos actualizada tan pronto como sea posible.
Para restablecer la creación de reflejo con la base de datos actualizada como la base de datos principal inicial, utilice esta copia de seguridad (y al menos una copia de seguridad del registro posterior) para crear una base de datos reflejada. Se debe aplicar cada copia de seguridad del registro tomada después de quitar la creación de reflejo. Por lo tanto, se recomienda retrasar otras copias de seguridad del registro adicionales de la base de datos principal hasta que se inicie la sesión de creación de reflejo.
Para forzar el servicio
Para reanudar la creación de reflejo de la base de datos
Para crear una nueva base de datos reflejada
Para iniciar la creación de reflejo de la base de datos
Vea también