Download Modulo 8 Disponibilidad de Datos y Replicación en SQL Server

Modulo 8
Disponibilidad de Datos y Replicación en SQL Server 2005
○
Introducción a la Disponibilidad de Datos
○
Failover Clustering
○
Database Mirroring
º
Mejoras en Replicación
Introducción a Disponibilidad de Datos
Introducción
Idealmente, un sistema de base de datos debería estar disponible las 24 horas del día, cada día. En
realidad, esto no es siempre posible, hay técnicas que puede usar para incrementar la disponibilidad de
sus aplicaciones. El SQL Server 2005 provee tres tecnologías que pueden ayudarlo a crear sistemas de
base de datos altamente disponibles: clustering, log shipping, y database mirroring.
Clustering
Clustering provee soporte de servidor completo y alta disponibilidad en caso de tener una falla de
hardware o mantenimiento agendado. En caso de falla, el sistema operativo y SQL Server trabajan
juntos para proveer un sistema automatizado para fallas. En el caso de agendar que la computadora no
funcione, puede configurar un nodo para que falle sobre otro para asegurarse que las aplicaciones aun
están disponibles para los usuarios. Ha sido posible tomar ventaja del clustering de Microsoft
Windows® en las ediciones previas de SQL Server, pero SQL Server 2005 Enterprise Edition mejora y
extiende estas capacidades:
El SQL Server 2005 soporta hasta ocho nodos cuando esta corriendo en Microsoft Windows Server.
2003 Datacenter Edition, incrementando la capacidad de failover.
!
El SQL Server 2005 también extiende la funcionalidad de clustering para permitirle ver el clustering
en conjunción con Analysis Services, Notification Services, y SQL Server Replication.
!
Log shipping
Log shipping provee un calido standby de sus datos que puede ser traído online en caso de falla del
sistema. Una base de datos completa es restaurada a un servidor secundario, y luego los logs de
transacción de la base de datos primaria son aplicados constantemente a la base de datos secundaria.
Este es un costo relativamente bajo a la solución de la disponibilidad de datos.
Log shipping esta disponible solo para usuarios de bases de datos, no sistemas de bases de datos. Esto
significa que debe tener un régimen estricto de backup las bases de datos master y msdb en el
servidor primario y restaurarlos en el secundario. Sin este régimen, cualquier metadato cambiado será
perdido en la falla del sistema, resultando potencialmente en logins, trabajos y alertas perdidos.
Database mirroring
Database mirroring es una nueva técnica disponible en SQL Server 2005 Enterprise Edition que
provee una versión mejorada de log shipping para un failover mas rápido. En lugar de shipping
transaction logs e una constante, intervalos configurados, cada transacción es shipped mientras que es
aplicada al servidor primario. No puede configurar un mirror set para automáticamente fail over en el
caso en que el servidor primario falle, y puede programar aplicaciones de cliente para
automáticamente reconectarse con el nuevo servidor primario.
Como log shipping, el mirroring de la base de datos esta disponible solo a usuarios de base de datos, y
requiere que asegure manualmente la disponibilidad y corrección de su sistema de base de datos.
Seleccione una Solución de Alta Disponibilidad
Es importante entender que ninguna de las soluciones de alta disponibilidad en SQL Server 2005 es
una opción aislada. Puede combinar dos o más técnicas dentro del mismo sistema para cubrir todas las
eventualidades.
La siguiente tabla compara y contrasta tres de las tecnologías de alta disponibilidad en SQL Server
2005.
Atributo Disponible
Clustering
Log shipping
Database
mirroring
Detección de Falla
Si
No
Si
Failover Automático
Si
No
Si
Perceived downtime
30 segundos +
recupero
N/A
Menos de tres segundos
Potencial de datos
perdidos
Si una copia de datos
Si la ultima
transacción log
Si en algunas
configuraciones
Masking of storage
failure
Sin disco compartido
Si
Si
Requerimientos
especiales de hardware
Almacenamiento y
servidores certificados
No
No
Distancia limitada
Yes.about 100
miles
No
No
Rango
Base de datos de sistema
y usuario
Base de datos de usuario
Base de datos de Usuario
Puede usar replicación en combinación con soluciones de alta disponibilidad para dar mayor
protección de datos de su sistema.
Introducción a Mirroring de Base de Datos
Introducción
Mirroring de base de datos puede proveer una solución failover casi instantánea para las bases de
datos SQL Server 2005. En esta edición, mirroring de base de datos le permite mantener una copia
actualizada de su base de datos en un servidor aparte para eventos de failover durante una falla del
servidor. Esta sección le enseña el concepto de mirroring una base de datos.
Objetivos de la sección
Luego de completar esta sección, usted podrá:
! Definir mirroring de base de datos.
! Identificar los roles realizados por los servidores en escenarios de mirroring de base de datos.
! Describir como funciona una sesión de mirroring.
! Describir como las diferentes configuraciones se comportar en las diferentes fallas del servidor.
! Describir los conceptos de mirroring de una base de datos.
Qué es Mirroring de Base de Datos?
Introducción
Mirroring de base de datos es una solución de software para incrementar la disponibilidad de la base
de dato. Mirroring de base de datos en SQL Server 2005 mejora el nivel de disponibilidad que tenían
las versiones anteriores de SQL Server y provee una alternativa fácil al clustering failover.
Definición
Mirroring de base de datos funciones manteniendo un servidor en standby que tiene un copia de la
base de datos. Si el servidor de producción falla, las aplicaciones pueden ser redireccionadas al
servidor en standby. El failover puede ser la mas instantánea, típicamente necesita de menos de tres
segundos si es realizada automáticamente.
La base de datos sobre la cual se hace el mirror es usualmente referida como la base de datos
principal; el mirror es llamado la base de datos mirror. (Debe entender que estos términos son
puramente relativo, ya que es posible para las bases de datos cambiar los roles como resultados de
failover.) Los servidores que tienen estas bases de datos se los llama partner servers.
Redirección Transparente para el Cliente
Su las aplicaciones de su cliente usan el SQL Native Client Library (SNAC) provisto con SQL Server
2005, pueden tomar ventaja de la redirección transparente para el cliente. SNAC es conciente que el
servidor al que esta conectado es el mirror y cacheara el nombre del servidor mirror. En el caso de
falla del servidor principal, la sesión del cliente será perdida. El cliente intentara reconectarse al
servidor principal, pero si falla, automáticamente redireccionara la conexión al servidor mirror.
Estados de las Bases de Datos
Hacer un mirror de una base de datos envuelve algunos pasos, durante los cuales la base de datos pasa
por algunos estados:
" Estado de sincronización. Para permitir hacer el mirror, la base de datos mirror debe ser creada, y
todos los cambios realizados a la base de datos principal también deben ser aplicados a la base de
datos mirror. Mientras que esto sucede, la base de datos principal y la mirror están en estado de
sincronización.
" Estado de sincronización. Una vez que la base de datos mirror se actualizo con la base de datos
principal, ambas están en estado de sincronización. Todos los cambios hechos a la base de datos
principal serán automáticamente hechos en la base de datos mirror para asegurarse que permanecen
sincronizadas.
" Estado desconectado. Si un servidor pierde conexión con su servidor/es partner como un falla de la
red, la base de datos pasa a estado desconectado.
" Estado Suspnedido. El mirror puede ser detenido temporalmente, usualmente como resultado de
acciones hechas por administrador de la base de datos. Una vez que la base de datos no esta siendo
espejada, entra en estado suspendido.
Los pasos para configurar un mirror y la transición que realiza cada base de datos son descriptas en
mas detalle en esta lección.
Modos de Operación
Los mirror de las bases de datos pueden operar en dos modos, que determinan el grado de exposición
a la perdida de datos y la naturaleza del failover que pueda realizarse:
" Modo sincronizado. En modo sincronizado, los registros de transaction log son transmitidos de la
base de datos principal a la base de datos mirror, y aplicados a la base de datos mirror antes de ser
hechos en la base de datos principal. Este mecanismo garantiza que no habrá transacciones perdidas, a
expensas del tiempo adicional que requiere completar una transacción. Este modo soporta failover
manual y automático.
" Modo desincronizado. En modo desincronizado, las transacciones son hechas primero en el servidor
principal antes de enviar registros log a la base de datos mirror. La base de datos mirror esta en estado
de desincronizacion perpetuo. Las aplicaciones no son demoradas mientras la comunicación con el
servidor mirror se produce. Esto incrementa el trabajo al peligro de perder la sincronizacion con la
base de datos mirror si la comunicaron falla. El modo desincronizado no soporta failover, aunque un
administrador de base de datos puede realizar pasos para forzar el uso de una base de datos mirror en
caso que la base de datos principal este no disponible. Sin embargo, la base de datos mirror puede no
haber sido actualizada con los mas recientes cambios.
El modo desincronizado de mirror es preferible a log shipping porque el intervalo de sincronizacion
ente bases de datos esta basada en transacciones en vez de logs de archivos enteros. Adicionalmente,
hacer mirror requiere menos administración que log shipping.
Nota
En SQL Server 2005 Beta 3, ambas bases de datos envueltas en el mirror deben operar en modo de
recuperacion completa.
Rol de los Servidores en el Mirroring de Base de Datos
Introducción
El mirror de la base de datos envuelve por lo menos dos partner servers que tienen la base de datos
principal y la mirror. Adicionalmente, otro servidor testigo puede ser usado para monitorear el mirror,
proteger la base de datos mirror, e implementar failover automático.
Servidor de Base de Datos Principal
El servidor servidor de base de datos principal tiene la base de datos principal. Este es el servidor al
cual los usuarios y aplicaciones se conectan normalmente para realizar sus tareas.
Servidor de la Base de Datos Mirror
El servidor de la base de datos mirror tiene la base de datos mirror. Los usuarios y aplicaciones no se
conectan a este usualmente a menos que ocurra un failover y este servidor es hecho el servidor de base
de datos principal. En este caso, luego que la comunicaron ha sido establecida con el servidor
principal, el servidor principal original puede tomar el rol de servidor mirror.
Los servidores de base de datos principal y mirror deben poder comunicarse entre ellos usando una
conexión confiable. Idealmente, ambos servidores deben pertenecer al mismo dominio.
Servidor Testigo
Un Servidor Testigo monitorea los servidores de base de datos principal y mirror y verifica que ambos
servidores estén disponibles. Como esto no es un trabajo intensivo, una computadora corriendo SQL
Server puede actuar como servidor testigo para cualquier set de mirrors.
Si el servidor de la base de datos principal o mirror fallan, el servidor testigo puede trabajar con el
servidor que sobreviva para reconectarse o reaccionar apropiadamente. Las acciones que se realizan,
que dependen de la configuración en curso de set de mirrors, son descriptas mas tarde en esta sección.
Sesiones de Mirror
Introducción
El mirror de la base de datos se realiza en el contexto de una sesion mirror. Una secion mirror
mantiene la infotmacion acerca del estado de las bases de datos, las mirror partners y el servidor
testigo.
Iniciar una sesión mirror
Cuando un administrador de base de datos inicia un una sesión mirror, el servidor de la base de datos
mirror identifica los registros log de las transacciones mas recientes que fueron aplicadas a la base de
datos mirror, y luego requiere cualquier registro log de transacciones subsiguiente del servidor
principal. Esta es la fase de sincronización de la sesión mirror.
Durante la sesión
Luego que la base de datos mirror esta sincronizada con la base de datos principal, el servidor de la
base de datos principal transmitirá todos los registros log de transacciones para la base de datos
principal a la base de datos mirror. Los registros log son transmitidos como cambios son hechos,
efectiva y continuamente rodando la base de datos mirror hacia la base de datos principal. El modo de
operación de la sesión mirror (sincronizada o desincronizada) determina si los registros de log de
transacciones serán aplicados a la base de datos mirror antes o después que las transacciones se
completen en la base de datos principal.
Una sesión mirror mantiene la información acerca del estado de cualquiera de los servidores testigo,
asegurándose que el servidor testigo esta visible y puede monitorear a los partner servers.
Terminar una Sesión Mirror
Una sesión puede ser terminada por una variedad de causas, las mas comunes son:
Falla en la comunicación de los servidores
Si el servidor principal se vuelve inaccesible, el servidor mirror puede ser hecho el servidor principal.
Esto puede ocurrir automáticamente, dependiendo del modo de operación en la sesión mirror y la
presencia de un servidor testigo.
!
Intervención manual del administrador de la base de datos.
El administrador de la base de datos puede terminar manualmente el mirroring usando comandos
Transact-SQL ALTER DATABASE. una sesión puede ser terminada completamente de esta manera,
o un mirroring puede ser simplemente suspendido, para reanudarse mas tarde. (Las bases de datos
pararan a la fase de sincronización otra vez hasta que la sesión continué.)
!
Nota
Luego que una sesión mirror ha comenzado, los usuarios no podrán conectarse a la base de datos
mirror. Este es un mecanismo de seguridad que previene a la base de datos de cambios accidentales.
La base de datos mirror permitirá el acceso solo luego de un failover (cuando toma el rol de base de
datos principal), o si el administrador de la base de datos lo permite.
Los comandos ALTER DATABASE usados para controlar una sesión mirror son descriptos mas
detalladamente en esta sección.
Configuraciones de Base de Datos Mirroring
Introducción
Hay varias maneras de configurar un set de mirrors. El comportamiento de los sets depende de un
numero de factores, incluyendo la presencia de un servidor testigo y el modo de operación
(sincronizado o desincronizado).
Para establecer cualquier tipo de sesión mirror, primero debe restaurar la base de datos desde el
servidor principal dentro del servidor mirror, y luego aplicar los logs de transacción al servidor mirror.
Luego puede establecer la sesión usando las statement ALTER DATABASE con la cláusula SET
PARTNER en cada servidor. tiene la opción de crear un servidor testigo usando la stament ALTER
DATABASE con la cláusula SET WITNESS. Una vez que la sesión es iniciada, las transacciones
que ocurran en el servidor principal serán mirrored en el servidor mirror.
Diferentes configuraciones tendrán diferentes comportamientos ambas durante la sesión y si o el
servidor principal o el mirror fallan, como se describe en los siguientes escenarios.
Escenario: Mirroring Sincronizado con Servidor Testigo
Mirror sincronizado con un servidor testigo provee la mas alta disponibilidad de mirror de base de
datos porque soporta failover automático sin perdida de datos. Sin embargo, como es requisito que las
transacciones sean entradas en el log en el servidor mirror antes de serlo en el servidor principal, la
performance puede verse afectada.
En el modo de operación sincronizada, las transacciones no son comprometidas en el servidor
principal hasta que hayan sido entradas en el log de transacción en el servidor mirror y un mensaje de
éxito ha sido recibido. el comportamiento resultante cuando un servidor se vuelve no disponible,
depende en cual servidor ha fallado, como se describe a continuación:
Servidor Principal. Si el servidor principal se vuelve no disponible por cualquier razón, el servidor
testigo instruirá al servidor mirror a tomar el rol de servidor principal. El servidor mirror traerá la base
de datos mirror online y a los usuarios y aplicaciones que son servidas. A este punto, la sesión mirror
es suspendida porque no hay mirror disponible para el nuevo servidor principal. Cuando el servidor
principal original es recuperado, tomara el rol de servidor mirror del nuevo servidor principal. Si es
Nazario, puede iniciar un failover manual para revertir estos roles a la configuración inicial.
!
Servidor Mirror. Si el servidor mirror se vuelve no disponible, el servidor principal seguirá
operando, pero en un estado suspendido. El Mirroring puede ser reestablecido restaurando el servidor
mirror.
!
Escenario: Mirroring Desincronizado con un Servidor Testigo
Mirroring desincronizado con un servidor testigo provee una alta disponibilidad con buena
performance porque las transacciones pueden ser comprometidas en el servidor principal
inmediatamente. Esta configuración es particularmente útil cuando hay una larga distancia o tardanza
entre los servidores principal y mirror.
En el modo de operación desincronizada, las transacciones son comprometidas en el servidor principal
y enviadas al log de transacciones del servidor mirror. Esto puede incrementar el trabajo porque el
compromiso en el servidor principal no esta esperando comunicación del servidor mirror. El
comportamiento cuando un servidor en un set de mirror desincronizado se vuelve no disponible es
descrito a continuación:
Servidor Principal. Si el servidor principal no esta disponible, el servidor testigo no puede iniciar
failover automático y la base de datos se vuelve no disponible. Puede manualmente forzar el servicio
en el servidor mirror para hacerlo asumir el rol de servidor principal de base de datos y servir su copia
de la base de datos a los usuarios y aplicaciones. Sin embargo, esto puede resultar en la perdida de
transacciones que fueron comprometidas en el servidor principal antes que falle pero aun no fueron
cometidas en el servidor mirror. Cuando el servidor principal original es restaurado, el servidor testigo
lo instruirá a volverse el servidor mirror para la base de datos.
!
Servidor Mirror. Si el servidor mirror se vuelve no disponible, el servidor principal continuara
operando, pero en un estado suspendido. El mirroring puede ser reestablecido recuperando el servidor
mirror y resumiendo la sesión.
!
Escenario: Mirroring Sincronizada sin un Servidor Testigo
El mirroring sincronizado sin un servidor testigo le permite garantizar que los datos en ambos
servidores son siempre concurrentes. Esta configuración es útil cuando necesita garantizar la
integridad de los datos y puede tolerar que el servidor no este disponible e issues de performance
potenciales.
La ausencia de un servidor testigo impacta los efectos de la falla de un servidor mirror en el modo
sincronizado. Failover automático no puede ocurrir porque no hay suficientes servidores para formar
una decisión quórum de cual servidor debe tomar el rol de servidor principal y cual el de servidor
mirror. El comportamiento resultante cuando un servidor no esta disponible y no hay servidor testigo
es descrito a continuación:
Servidor Principal. Si el servidor principal se vuelve no disponible, la base de datos también se
vuelve no disponible. Forzar manualmente al servidor mirror a servir y resumir la sesión mirror una
vez que el servidor principal esta otra vez online.
!
Servidor Mirror. Si el servidor mirror se vuelve no disponible, el servidor principal pondrá la base de
datos offline. Esta acción es para maximizar la protección de la base de datos y asegurar la integridad
de sus contenidos. Una vez que el servidor mirror es reiniciado, el servidor principal se vuelve
disponible automáticamente otra vez.
!
Configurar Mirroring de Base de Datos
Introducción
Crear una sesión mirror envuelve configurar un Server mirror, estableciendo una sesión, y ,
opcionalmente, establecer un servidor testigo. Otras tareas de administración incluyen inicializar
failovers manualmente para propósitos de mantenimiento y terminar sesiones. Esta sección le mostrara
como configurar y usar mirroring de una base de datos.
Objetivos de la sección
Luego de completar esta sección, usted podrá:
! Configurar un servidor mirror.
! Configurar mirroring endpoints.
! Establecer una sesión mirror.
! Establecer un servidor testigo.
! Administrar sesiones mirror.
! Configurar mirroring de base de datos.
Como Configurar un Servidor Mirror
Introducción
Antes de configurar un mirroring de base de datos y establecer una sesión mirror debe configurar el
servidor mirror y la base de datos.
Servidor Mirror
El servidor que tiene la base de datos, debe ser accesible y confiable por el servidor principal de base
de datos. Idealmente, el servidor principal y el servidor mirror deben pertenecer al mismo dominio.
Adicionalmente, si el servidor mirror es tentado a proveer servicio en un failover, esa computadora
debe tener suficiente memoria y poder de proceso para actuar como un sustituto del servidor principal
de base de datos. Debería poder soportar usuarios y aplicaciones sin diferencia notable en la calidad
del servicio.
Nota
El servidor mirror puede ser una instancia en la misma computadora que le servidor principal de base
de datos. Sin embargo esto no es recomendable, porque impactara la performance y la recuperabilidad
de la base de datos en caso de una falla seria de hardware. Para que ocurra un failover automatico
confiable, la base de datos mirror y la base de datos principal debem estar en computadoras diferentes.
Bases de Datos Mirror
Debe crear una base de datos mirror manualmente. Por simplicidad, la estructura de archivos de la
base de datos mirror debe coincidir con la base de datos principal. Ambas bases de datos deben
implementar el modelo de recuperación completa. Luego que la base de datos mirror ha sido creada,
debe aplicar el backup mas reciente de la base de datos completa de la base de datos principal a la
base de datos mirror usando el comando RESTORE DATABASE con la cláusula WITH
NORECOVERY.
Nota
Es importante que use la opción WITH NORECOVERY, porque la base de datos mirror debe
permanecer en el estado de restauración para que los registros de transacción log sean aplicados
durante el mirroring.
Cómo Configurar Mirroring Endpoints
Introducción
Antes de establecer una sesión mirror, debe configurar el mecanismo de configuración por el cual el
mirroring ocurrirá. Esto envuelve asegurarse que los endpoints apropiados son creados en cada
instancia de servidor que practicaran en las operaciones mirroring. Un endpoint simplemente controla
el puerto Transmission Control Protocol (TCP) en el cual una instancia de servidor escucha los
mensajes para una base de datos mirroring. Un endpoint también define el rol que ese endpoint debe
realizar.
Una instancia de servidor requiere solo un endpoint en el cual escuchar, sin importar en cuantas
sesiones de mirroring participa. Sin embargo, cada instancia requiere un único puerto en el cual
escuchar, por lo tanto, si su servidor tiene instancias múltiples de SQL Server participando en una
sesión mirror, cada instancia requiere su propio endpoint, configurado con un único puerto TCP.
Crear un Partner endpoint en el Servidor Mirror
Un servidor mirror requiere un partner endpoint para que pueda comunicarse con los servidores
principales para actividades de mirroring. El siguiente código crea partners endpoint llamados
mirroring_ep y especifica que debe volverse activo inmediatamente seteando el parámetro STATE a
STARTED. También especifica que el puerto TCP 5022 debe ser usado para escuchar las operaciones
de mirroring . El puerto 5022 es el puerto TCP por defecto para operaciones de mirroring de SQL
Server 2005. el ejemplo también muestra como setear el rol del endpoint a PARTNER.
--Endpoint for the mirror server
CREATE ENDPOINT mirroring_ep
STATE=STARTED
AS TCP(LISTENER_PORT=5022)
FOR DATABASE_MIRRORING
(ROLE=PARTNER)
Crear un Partner endpoint en el Servidor Principal
Si su escenario mirroring incluye un servidor testigo, también necesitara crear un endpoint en la
instancia de SQL Server que proveerá servicio testigo. La sintaxis para crear un endpoint testigo es
similar a la usada para crear partner endpoints, con la exclusión que necesita especificar el rol
WITNESS. El siguiente código crea un endpoint para un servidor testigo:
--Endpoint for the witness server
CREATE ENDPOINT mirroring_ep
STATE=STARTED
AS TCP(LISTENER_PORT=5022)
FOR DATABASE_MIRRORING
(ROLE=WITNESS)
Como antes, si otra instancia de SQL Server en la misma computadora ya esta usando el endpoints
para sesiones mirroring, deberá elegir un puerto único para la instancia de SQL Server que esta
actuando como testigo.
Cómo Establecer una Sesion Mirror
Introducción
Luego de haber preparado el servidor y base de datos mirror y crear el endpoint apropiado, debe
iniciar una sesión mirror estableciendo el servidor de base de datos principal y mirror como partners.
Los siguientes ejemplos están basados asumiendo que quiere hacer un mirror de la base de datos
AdventureWorks en el servidor London al servidor Manchester. El ejemplo también asume que el
puerto TCP por defecto 5022 es usado por el mirroring endpoints en cada servidor.
Crear un mirroring en una Relación de Partners
Corra el comando ALTER DATABASE con la cláusula SET PARTNER para crear una relación de
partners entre los servidores:
ALTER DATABASE database_name
SET PARTNER = 'server_network_address'
Corra el comando ALTER DATABASE en el servidor mirror primero, especificando la dirección
endpoint del servidor principal como el parámetro server_network_address. Esto pondrá a la base de
datos mirror en un estado listo para iniciar la sincronización cuando sea contactado por el servidor
principal. Por ejemplo, para configurar un mirror para la base de datos AdventureWorks en el servidor
London, usando el siguiente statement:
ALTER DATABASE AdventureWorks
SET PARTNER = 'TCP://London:5022'
Cuando la base de datos mirror esta lista para comenzar la sincronización, corra el comando ALTER
DATABASE en el servidor principal, especificando el servidor mirror como el parámetro
server_network_address. Para especificar que el servidor Manchester esta configurado para actuar
como el mirror del servidor London, corra el siguiente comando en el servidor London:
ALTER DATABASE AdventureWorks
SET PARTNER = 'TCP://Manchester:5022'
La sincronización y la sesión mirror comenzaran; ambas bases de datos pasar al estado de
sincronización antes de entrar al estado sincronizado.
Cambiar el Modo de Operación
Por defecto, una sesión de mirror opera en modo sincronizado. puede cambiar el modo de operación
de una sesión mirror usando el comando ALTER DATABASE con la cláusula SET PARTNER
SAFETY en cualquier servidor partner:
ALTER DATABASE database_name
SET PARTNER SAFETY <safety_mode>
El parámetro safety_mode puede estar en OFF (para modo desincronizado), o FULL (para modo
sincronizado). Por ejemplo, especificar el modo sincronizado para la sesión mirror configurada antes,
ejecute el siguiente comando en cualquier servidor, el London o el Manchester:
ALTER DATABASE AdventureWorks
SET PARTNER SAFETY FULL
Ver Información de Mirrors en Relacion de Partners
Puede consultar la vista del catalogo sys.databases para examinar la relación de partners mirror entre
bases de datos. La siguiente tabla describe las columnas conteniendo información de mirroring útil.
Columna
Descripción
mirroring_state_desc
Una descripción textual del estado de la base de datos.
Esta columna tendrá alguno de los siguientes valores:
DISCONNECTED
SYNCHRONIZED
SYNCHRONIZING
SUSPENDED
PENDING_FAILOVER
mirroring_partner_name
La dirección de red del mirroring partner.
mirroring_witness_name
La dirección de red del servidor testigo, o nada si no
hay testigo presente.
mirroring_witness_state_desc
Una descripción textual del estado del servidor testigo.
Esta columna tendrá algunos de los siguientes valores:
UNKNOWN
CONNECTED
DISCONNECTED
mirroring_role_desc
Una descripción del rol de la base de datos. Esta
columna tendrá los siguientes valores:
PRINCIPAL
MIRROR
mirroring_safety_level_desc
Una descripción del modo de operación de la base de
datos. Esta columna tendrá los siguientes valores:
UNKNOWN
OFF (desincronizado)
FULL (sincronizado)
mirroring_safety_sequence
Actualiza el numero de secuencia por cambios de
transacción a nivel de seguridad.
mirroring_failover_lsn
EL numero de secuencia de log en el ultimo failover.
Nota
Si una base de datos no participa en una sesión mirror, todas las columnas mirror en sys.databases
para esa base de datos, contendrán valores null.
También puede usar los contadores de performance del set mirror en el objeto de base de datos del
servidor para monitorear la actividad dentro de su set mirror.
Cómo Establecer un Servidor Testigo
Introducción
Si quiere implementar el failover automático, debe establecer un servidor testigo en su set mirror. El
servidor testigo debe estar en una computadora diferente del servidor principal y el mirror, Sin
embargo, un servidor puede actuar como testigo mirror para varias relaciones de partners.
Crear un Testigo
Use el comando ALTER DATABASE con la cláusula SET WITNESS en el servidor principal para
crear un servidor testigo:
ALTER DATABASE database_name
SET WITNESS = 'server_network_address'
Especifique la dirección del servidor testigo y el punto endpoint para actuar como el testigo para el
parametro server_network_address Por ejemplo, para crear un testigo en un servidor llamado
Birmingham para la sesión de mirror entre los servidores London y Manchester discutidos antes, corra
el siguiente comando en el servidor London:
ALTER DATABASE AdventureWorks
SET WITNESS = 'TCP://Birmingham:5022'
Nota
Failover automático correrá si la sesión mirror es establecida usando el modo de operación
sincronizado, un servidor testigo ha sido creado, y las bases de datos principales y mirror están
corriendo en computadoras separadas.
Remover un Testigo
Puede deshabilitar un testigo de una sesión mirror usando el siguiente comando en cualquiera de los
servidores partner:
ALTER DATABASE database_name
SET WITNESS OFF
Con el servidor testigo deshabilitado, la sesión mirror continuara, pero el failover automático no será
posible y el failover deberá ser realizado manualmente.
Nota
El failover manual solo es posible si la sesión mirror es usada en el modo de operación sincronizado.
Ver Información del Servidor Testigo
La vista de catalogo sys.database_mirroring_witnesses contiene información acerca del servidor
testigo. Las columnas de interés de esta vista están resumidas en la siguiente tabla.
Columna
Descripción
database_name
La dirección de red de la base de datos sobre la cual se
esta haciendo el mirror.
principal_server_name
La dirección de red del servidor que tiene la base de
datos principal.
mirror_server_name
La dirección de red del servidor que tiene la base de
datos mirror.
safety_level_desc
Una descripción textual del modo de operación en
curso. Esta columna tendrá los siguiente valores:
UNKNOWN
OFF (desincronizado)
FULL (sincronizado)
Cómo Administrar Sesiones Mirror
Introducción
En presencia de un servidor testigo, el failover ocurrirá automáticamente si el servidor principal falla.
Sin embargo, si no hay servidor testigo disponible, debe hacer un failover manual. Si la base de datos
principal no esta disponible y las bases de datos no están sincronizadas, el failover no puede ocurrir y
debe forzar el servicio a hacer el mirror de la base de datos.
También puede suspender y resumir una sesión mirror para aliviar temporalmente issues de una
performance y terminar sesiones permanentemente.
Realizar un Failover Manual
Puede realizar un failover manual para hacer actualizaciones de hardware u otras operaciones de
mantenimiento en el servidor principal. Failing over asegura que la base de datos este disponible
cuando el servidor principal esta offline.
Si nenecita poner el servidor principal offline, ejecute el comando ALTER DATABASE con la
cláusula SET PARTNER FAILOVER en el servidor principal para iniciar un failover manual:
ALTER DATABASE database_name
SET PARTNER FAILOVER
El servidor mirror completara cualquier recuperación y se pondrá en online. La base de datos mirror y
la principal intercambiaran los roles. Puede llevar el servidor principal original (ahora el mirror)
offline y realizar cualquier mantenimiento requerido. Cuando ponga el servidor otra vez online, puede
poner las bases de datos en sus roles originales y repetir este proceso en el nuevo servidor principal.
Forzar el Servicio
El failover es solo posible cuando la sesión mirror usa el modo de operación sincronizado. Para
sesiones que corren desincronizadas, debe forzar el servicio en el servidor mirror para ponerlo online.
Sin embargo, hay peligro que no todos los registros de transacciones log se hayan propagado en la
base de datos mirror; algunos cambios recientes pueden ser perdidos.
Para forzar el servicio en el servidor mirror, use el comando ALTER DATABASE con la cláusula
SET PARTNER FORCE_SERVICE_ALLOW_DATA_LOSS en el servidor mirror:
ALTER DATABASE database_name
SET PARTNER FORCE_SERVICE_ALLOW_DATA_LOSS
La mirror de la base de datos será recuperada tan pronto como sea posible y será puesta online. la base
de datos mirror entrara en estado suspendido. cuando el servidor principal se haya recuperado,
también será marcado como suspendido.
Suspender y Resumir Sesiones Mirror
Puede suspender temporalmente las sesiones mirror y luego resumirlas y sincronizar las bases de
datos. Por ejemplo, si se forma un bottleneck, debe querer permitir a todos las transacciones
simplemente completarse en el servidor principal y luego aplicarlos a la base de datos mirror.
Suspender una sesión causa que todas las logs de transacción en el servidor principal crezcan mientras
que cada transacción es logged y almacenada. Hasta que la sesión mirror es resumida o terminada, el
log de transacción del servidor principal no puede ser truncado porque la transacción aun tiene que ser
aplicada al servidor mirror.
Use el comando ALTER DATABASE con la cláusula SET PARTNER SUSPEND en cualquier
servidor para suspender la sesión:
ALTER DATABASE database_name
SET PARTNER SUSPEND
Para resumir la sesión, use el comando ALTER DATABASE y con la cláusula SET PARTNER
RESUME:
ALTER DATABASE database_name
SET PARTNER RESUME
Terminar la Sesión Mirror
Puede terminar manualmente la sesión mirror y terminar la relación entre los servidores. Terminar la
sesión borra toda la información acerca de la sesión desde todos los servidores y deja ambos
servidores el principal y el mirror con una copia independiente de la base de datos. La base de datos
mirror permanecerá en un estado de restauración hasta que sea recuperada o borrada manualmente.
Use el comando ALTER DATABASE con la cláusula SET PARTNER OFF en cualquier servidor
para terminar la sesión:
ALTER DATABASE database_name
SET PARTNER OFF