Académique Documents
Professionnel Documents
Culture Documents
SQL Server
Volver a: [Database Mirroring en SQL Server 2005 y
SQL Server 2008]
Database Mirroring es una solucin alternativa de Alta Diponibilidad, nueva en SQL
Server 2005, que puede verse como la evolucin natural de Log Shipping (tecnologa
disponible en ediciones anteriores de SQL Server, basada en la entrega de Logs de
Transacciones sobre una copia de la base de datos en un servidor secundario en espera, es
decir, hacer RESTORE LOG WITH NORECOVERY a "tutti" ;-). As, existen varias
diferencias entre Database Mirroring y Log Shipping, por ejemplo, Log Shipping permite
funcionar en Modo de Recuperacin de Registro Masivo (Bulk-Logged) y en el Modo de
Recuperacin Completo, mientras que Database Mirroring slo puede funcionar en Modo
de Recuperacin Completo.
A diferencia de Log Shipping, Database Mirroring ofrece recuperacin automtica ante
fallos (automatic failover) sin necesidad de disponer de ninguna solucin hardware
especial ni propietaria, con lo cual, se muestra como una alternativa de bajo coste a las
soluciones basadas en Microsoft Cluster (o Server Clustering). Adems, para casos de
balanceo (failover), es posible desarrollar las aplicaciones cliente para que se reconecten automticamente a la base de datos activa (es decir, a la que acte como base
de datos principal), como se indica ms adelante en el captulo de Administracin y
Mantenimiento de Database Mirroring (ver la seccin Redireccin de Cliente:
ADO.NET / SQL Native Client automatic redirection).
Es importante tener en cuenta, que a da de hoy, en cualquier mediana o gran empresa
abundan las soluciones SAN (ej: almacenamiento HP EVA, redes y switches de fibra, etc.)
y los servidores Wintel con interfaces HBA (ej: servidores HP Blade, HP SuperDome, etc),
infraestructuras sobre las cuales es posible construir soluciones Microsoft Cluster de forma
sencilla y econmica (es decir, tomando como premisa la existencia de dicha
infraestructura, no es necesario ningn elemento adicional para montar un Microsoft
Cluster, por lo tanto, nos da igual montar SQL Server sobre Microsoft Cluster o un
Database Mirroring, desde el punto de vista de costes adicionales, al menos en principio).
Una ventaja de montar Database Mirroring en vez de Microsoft Cluster (o Server
Clustering), la podramos encontrar si tuviramos que ofrecer Alta Disponibilidad de base
de datos para un producto que no est soportado su funcionamiento con bases de datos en
Cluster. Por poner un ejemplo real, en una instalacin MOSS 2007 (Microsoft Office
SharePoint Server 2007) o Microsoft Office Sharepoint Portal Server 2003 no estn
soportados para ejecutarse sobre bases de datos SQL Server 2005 en Cluster Geogrficos,
conforme muestra el artculo de soporte KB946791, aunque s se tratan de aplicaciones
Cluster-Aware (es decir, s pueden montarse sobre Microsoft Cluster, siempre y cuando, no
exista replicacin del almacenamiento entre ubicaciones fsicamente separadas). En este
caso, la forma de ofrecer un entorno de Alta Disponibilidad de base de datos
geogrficamente disperso, pasa por utilizar Database Mirroring (pudiendo ubicar los
servidores miembros de la correspondiente sesin de Mirroring, en ubicaciones fsicamente
distantes).
La comunicacin entre los diferentes servidores SQL Server de una topologa Database
Mirroring, se realiza a travs de Extremos o Endpoints de SQL Server especficos para
Database Mirroring, un tipo de objeto de servidor nuevo en SQL Server 2005, que
permiten la creacin de caminos de comunicacin con Instancias de SQL Server. La ventaja
de la utilizacin de Extremos o Endpoints, es que permiten configurar sus requisitos de
Autenticacin y Cifrado, ofreciendo as un camino de comunicacin ms o menos seguro
(en funcin de las necesidades de cada caso). Por defecto, la creacin de Extremos o
Endpoints (CREATE ENDPOINT) para Database Mirroring a travs del Asistente incluido
en SQL Server 2005, implicar la creacin de Extremos o Endpoints con Autenticacin y
Cifrado.
Database Mirroring, al igual que Log Shipping, slo protege a nivel de base de datos (es
decir, slo las bases de datos de usuario) y no a nivel de Instancia, para lo cual sera
necesario implementar Server Clustering (y as proteger tambin las bases de datos del
sistema y dems elementos que forman una instancia de SQL Server).
Database Mirroring es una tecnologa de Alta Disponibilidad basada en un modo de
funcionamiento Activo / Pasivo. Es decir, mientras una Instancia realiza un papel de
Servidor Principal (Activo) para una base de datos en particular, la otra instancia realiza el
papel de Servidor Espejo o Secundario (Pasivo) para dicha base de datos. En consecuencia,
no ser posible el acceso a la copia de la base de datos del Servidor Espejo, pues en dicho
caso, se producir un error como el siguiente:
Msg 954, Level 14, State 1, Line 1
The database "GuilleSQL" cannot be opened. It is acting as a mirror database.
Sin embargo, aunque el funcionamiento de Database Mirroring es Activo/Pasivo, tanto el
servidor Principal como el servidor Espejo hospedan ambos una copia de la base de datos,
con la peculiaridad de que la base de datos del servidor que acta como Espejo no
podr ser accedida (slo estar accesible la base de datos Principal), pues estar en modo
Mirror / Restoring. Claro est que podemos encontrar un pequeo truco si deseamos
acceder a la base de datos Espejo (Mirror), pues es posible crear un Database Snapshot
sobre la base de datos en Mirror, y seguidamente consultar dicho Database Snapshot
(evidentemente, slo podremos consultar los datos conforme estaban en un punto en el
tiempo, no siendo posible modificar datos). Algo sorprendente (al menos, a mi me lo
pareci cuando lo descubr), pues de hecho, sobre una base de datos en modo Restoring no
es posible crear un Database Snapshot, pero sin embargo, sobre una base de datos en Mirror
s es posible (que al fin y al cabo, se est comportando de un modo muy parecido al de
manual (manual failover). En caso de una cada o prdida del Servidor Espejo, la
base de datos principal dejar de estar activa, al haber perdido el Quorum.
Modo de Alto Rendimiento (asncrono y sin testigo). Las transacciones son
aplicadas de forma asncrona a la base de datos espejo, ofreciendo mejor
rendimiento que los anteriores modos de funcionamiento, pero pagando como
precio la existencia de posibles prdidas de transacciones (y en consecuencia,
potenciales prdidas de datos). Evidentemente, la recuperacin ante fallos se realiza
de forma manual (manual failover), hablando de conmutacin forzada (es decir,
cambio de roles sin comprobacin de datos escritos en el servidor espejo). En caso
de una cada o prdida del Servidor Espejo, el Servidor Principal no se ver
afectado.
Por poner un ejemplo, en el caso de MOSS 2007 (tambin con SharePoint Portal Server
2003), para ofrecer un sistema de Alta Disponibilidad basado en servidores SQL Server
geogrficamente dispersos, el modo de funcionamiento recomendado ser el Modo de Alta
Disponibilidad, debido a que MOSS 2007 (o SharePoint 2003) contiene mltiples bases de
datos, siendo necesario mantener la consistencia e integridad sobre todas las bases de datos
SQL Server utilizadas por MOSS 2007 (o SharePoint 2003). En consecuencia, tambin
sera posible utilizar el modo de funcionamiento de Alta Proteccin, en cuyo caso se
perdera la funcionalidad de recuperacin automtica ante fallos (Automatic Failover), pero
sin riesgo de prdida de datos. Un aspecto a tener en cuenta en caso de montar Database
Mirroring para MOSS 2007 o SharePoint 2003, es el tema de la configuracin de Alias
SQL, como se coment en un artculo anterior de Instalacin y Configuracin MOSS 2007.
A continuacin se incluye una tabla resumen de los modos de funcionamiento de Database
Mirroring en SQL Server 2005:
Modo
Recuperacin Posible
Servidor Testigo Transaction
Automtica Prdida
(Witness)
Safety
ante Fallos
de Datos
Alta Disponibilidad
SI
(High Availability)
Alta Proteccin
NO
(High Protection)
Alto Rendimiento
NO
(High Performance)
NO
SI
ON
NO
NO
ON
SI
NO
OFF
Servidor Principal en SQL Server 2005, y Servidor Espejo en SQL Server 2005.
Servidor Principal en SQL Server 2005, y Servidor Espejo en SQL Server 2008.
Servidor Principal en SQL Server 2008, y Servidor Espejo en SQL Server 2008.
Servidor Principal en SQL Server 2008, y Servidor Espejo en SQL Server 2005.
Lo cual implica, que si tenemos el Servidor Principal en SQL Server 2005 y el Servidor
Espejo en SQL Server 2008, deberemos tener especial cuidado con que se produzca un
balanceo (failover), ya que en este caso, el balanceo (failover) no ser reversible (no hay
donde rascar, se dice por aqu, en Carabanchel ;-).
En cualquier caso, resulta muy interesante el hecho de poder construir infraestructuras de
Database Mirroring con SQL Server 2005 y SQL Server 2008, por ejemplo, como mtodo
de migracin de SQL Server 2005 a SQL Server 2008 con escaso corte de servicio.
Una vez comentada esta curiosa posibilidad de Database Mirroring con SQL Server 2005
como Servidor Principal y SQL Server 2008 como Servidor Espejo (Mirror), aprovecho
para incluir las principales mejoras de SQL Server 2008 para Database Mirroring.
Una vez introducidos los pasos a realizar para la configuracin de Database Mirroring, a
continuacin se detalla cada uno de estos pasos, con el fin de poder detallar e incluir
ejemplos de configuracin de Database Mirroring que facilite la compresin de dicho
proceso, a modo de Gua o Manual de Configuracin de Database Mirroring, paso a paso:
Servidor Principal (ej: el inicio de sesin del Crawler - Index Server, etc.).
Aqu tambin tenemos algunos detalles importantes. Por ejemplo, en el caso de
utilizar Inicios de Sesin (Logins) de Directorio Activo, el SID utilizado se obtendr
de Directorio Activo, por lo tanto la creacin del Inicio de Sesin en el Servidor
Espejo (Mirror) no esconde truco alguno. Sin embargo, en el caso de Inicios de
Sesin de SQL Server, el SID es generado de forma aleatoria por SQL Server, y en
consecuencia, si creamos un Inicio de Sesin de SQL Server en el Servidor
Espejo (Mirror) se generar un SID diferente, y en caso de balanceo (failover)
nos encontraremos con Usuarios Hurfanos (es decir, el Inicio de Sesin perder
el acceso a la base de datos). Cmo solucionar este problema? Pues lo suyo, es la
utilizacin del mismo SID en los dos servidores (Principal y Espejo), para lo cual
podemos crear el nuevo Inicio de Sesin con una sentencia CREATE LOGIN
WITH SID (ej: CREATE LOGIN GuilleSQL WITH PASSWORD='segura',
CHECK_POLICY=OFF, SID=0xB228CA1014A7464AC7C1E31A27B1213A).
Recordemos que es posible conocer el SID asociado a un Inicio de Sesin,
consultando las vistas del sistema en la base de datos master, como las vistas del
catlogo sys.sql_logins y sys.server_principals. Evidentemente, la utilizacin del
procedimiento almacenado sp_change_users_login es una apa en este caso, que
malfuncionar, pues en cada balanceo ser necesario ejecutar dicho procedimiento
almacenado para corregir los Usuarios Hurfanos.
Otro problema tpico es el hecho de necesitar duplicar los trabajos del Agente de
SQL Server que acten sobre las bases de datos en Mirroring, de tal modo, que
estn en ambos servidores (Principal y Espejo), pues siempre que se modifique un
Job ser necesario replicar dicho cambio en el otro servidor. Pero la historia no
acaba aqu, ya que ser necesario que los Jobs slo acten sobre una base de
datos si dicha base de datos est como Principal en la instancia. Pongamos el
tpico ejemplo de la realizacin de Backups o Mantenimientos (ej: Reindexaciones),
los cuales slo debern de ejecutarse sobre la base de datos principal
(evidentemente, pues al intentar acceder a la base de datos Espejo recibirn un
bonito error, claro). Una forma de conseguir que los Jobs funcionen correctamente
es personalizarlos (o customizarlos, como ahora est de moda decir), condicionando
las tareas a realizar en funcin de si la base de datos a la que se necesita acceder
acta como Principal o como Espejo (Mirror). Para esto, es posible consultar la
vista del catlogo sys.database_mirroring, por ejemplo, para consultar el valor del
campo mirroring_role (el valor 1 significa Principal y el valor 2 significa Espejo Mirror) para la base de datos deseada, y en funcin de este campo, hacemos algo o
no lo hacemos. De este modo, podemos lanzar el mismo trabajo (Job) en ambos
servidores (Principal y Espejo), con la garanta de que slo se ejecutar sobre la
instancia que hospede la base de datos deseada como Principal.
Administracin y Mantenimiento de
Database Mirroring en SQL Server 2005 y
SQL Server 2008 (introduccin)
Volver a: [Database Mirroring en SQL Server 2005 y
SQL Server 2008]
Una vez configurado y puesto en marcha Database Mirroring en SQL Server, es
necesario estar preparados para administrar y mantener dicha infraestructura de Database
Mirroring, evitando cadas de servicio y entradas de incidencias. Aunque Database
Mirroring es una tecnologa con un bajo coste de mantenimiento (ms dolores de cabeza
genera la Replicacin de SQL Server, por ejemplo), es necesario tener en cuenta ciertas
peculiaridades en la administracin y mantenimiento de las bases de datos montadas en
Database Mirroring. Qu se debe tener en cuenta para la Administracin y
Mantenimiento de Database Mirroring en SQL Server?
Como en todas reas, podramos extendernos ampliamente para cubrir este tema. Sin
embargo, y para no abrumar, vamos a intentar hacer un captulo introductorio capaz de
presentar las principales problemticas, herramientas y comandos a tener en cuenta en la
administracin y mantenimiento de Database Mirroring. En particular, vamos a ver lo
siguente:
Como siempre, todo lo que se puede realizar desde un interfaz grfico, es posible realizarlo
tambin por comandos, utilizando Transact-SQL. En este caso, trataremos especialmente
con los comandos ALTER DATABASE SET PARTNER y CREATE ENDPOINT.
realizar en entornos de laboratorio, etc. En cualquier caso, se trata de una tarea muy
sencilla, pues para deshacer el Database Mirroring, tan slo es necesario ejecutar una
sentencia ALTER DATABASE SET PARTNER OFF, como se muestra en el siguiente
ejemplo:
ALTER DATABASE GuilleSQL SET PARTNER OFF
Tambin es posible realizarlo de forma grfica desde la pestaa Mirroring del dilogo de
Propiedades de la base de datos correspondiente (botn Remove Mirroring).
Despus de desconfigurar Database Mirroring con la anterior sentencia ALTER
DATABASE SET PARTNER OFF o desde SSMS, es posible volver a configurarlo (si
fuese necesario, por ejemplo, por haber deshabilitado Database Mirroring por error) sin
necesidad de volver a ejecutar sentencias de BACKUP ni de RESTORE, es decir,
directamente ejecutando las correspondientes sentencias ALTER DATABASE SET
PARTNER (como se vi anteriormente, en el apartado de configuracin de Database
Mirroring). Esto es as (probado), siempre y cuando no perdamos transacciones en la base
de datos principal (ej: truncar el Log).
De hecho, al ejecutar la sentencia ALTER DATABASE SET PARTNER OFF, la base de
datos Principal se quedar activa como una base de datos normal y corriente (sin Database
Mirroring, ni n de n), mientras que la base de datos Espejo se quedar en estado
Restoring, igual que la dejamos cuando ejecutamos los RESTORE WITH NORECOVERY
utilizados inicialmente para configurar el Database Mirroring. Por este motivo, tenemos la
posibilidad de volver a configurar el Database Mirroring, o bien, si lo deseamos podemos
configurar la base de datos del Espejo como una base de datos activa ejecutando una
sentencia RESTORE WITH RECOVERY (ej: RESTORE DATABASE GuilleSQL
WITH RECOVERY).
En cualquier caso, una vez que se ha roto la sesin de Database Mirroring con la sentencia
ALTER DATABASE SET PARTNER OFF, y si queremos dejar la casa limpia, el
siguiente paso sera eliminar los ENDPOINT creados para el Database Mirroring (en el
Principal, Espejo y Testigo), mediante sentencias DROP ENDPOINT (ej: DROP
ENDPOINT Mirroring) en cada uno de los servidores. Eso s, eliminaremos los
ENDPOINT si no existe ninguna otra sesin de Database Mirroring (es decir, si no se estn
utilizando, claro).
Parar una sesin de Database Mirroring suspende el Mirroring, lo cual implica que se
detiene el envo de transacciones desde la Base de Datos Principal a la Base de Datos
Espejo (Mirror). Esta situacin nos va a permitir obtener una mejora de rendimiento
adicional, que puede resultar de gran utilidad para realizar alguna tarea de mantenimiento o
ejecutar algn proceso que genere muchas escrituras en base de datos. Sin embargo, nos va
a traer un riesgo adicional, debido a que no se podrn truncar transacciones de los
ficheros de Log (an haciendo backups de Log), lo cual podra llegar incluso a llenar
completamente el disco, impactando en el servicio de base de datos. Por ello, en caso de
pausar una sesin de Database Mirroring, es importante reanudar dicha sesin de Database
Mirroring lo antes posible, as como vigilar el crecimiento del Log en la base de datos
Principal mientras la sesin de mirroring se mantenga pausada. Tambin es importante
tener en cuenta, que al reanudar la sesin de Database Mirroring, se enviarn las
transacciones acumuladas en Log desde la base de datos Principal a la base de datos Espejo
(Mirror).
A continuacin se incluyen las sentencias Transact-SQL (ALTER DATABASE SET
PARTNER) correspondientes a pausar y reaundar una sesin de Database Mirroring:
ALTER DATABASE GuilleSQL SET PARTNER SUSPEND
ALTER DATABASE GuilleSQL SET PARTNER RESUME
En una conexin a una base de datos SQL Server configurada en Database Mirroring,
realizada a travs de ADO.Net o SQL Native Client, permite que pueda realizarse una
Redireccin Automtica de la conexin a SQL Server. Es decir, si el cliente al conectarse a
SQL Server detecta que el Servidor Principal est cado, ser capaz de conectarse a travs
del Servidor Espejo (Mirror). Del mismo modo, si una vez el cliente ha conectado con SQL
Server, se produce un failover, en la siguiente ocasin que el cliente necesite acceder a la
base de datos, ser capaz de reconectarse automticamente al servidor que acte como
Servidor Principal.
La Redireccin Automtica del cliente en una infraestructura de Database Mirroring, es una
funcionalidad muy apreciada, y en este caso, es tan fcil como utilizar una sintaxis
determinada en la cadena de conexin a SQL Server, como se muestra en el siguiente:
"Data Source=SrvPrincipal;Failover Partner=SrvMirror;Initial
Catalog=GuilleSQL;Integrated Security=True;"
De este modo, una aplicacin que utilice esta funcionalidad (ej: una Aplcacin Web de
ASP.Net) ser capaz de reconectarse automticamente en caso de balanceo (failover),
reducindose el coste de mantenimiento de la infraestructura.
Y con esto acaba este captulo. Evidentemente, con este contenido no seremos los ms
expertos en Database Mirroring con SQL Server, pero seguro que tendremos una idea