
Este artículo se referirá a la implementación de mirroring para SQL SERVER 2005. El foco es la tolerancia a fallos, no la alta disponibilidad. Para este artículo, nos basamos en un ejemplo sobre 2 servidores SQL 2005.
Entorno: tenemos un servidor SQL SERVER 2005 al cual queremos dotar de tolerancia a fallos sin failover automático(para el failover automático, entraría en juego un tercer servidor (witness)). Así pues tenemos dos “instancias”, principal y mirror.
Hacemos un backup completo de la base de datos a replicar. Movemos el backup al mirror y restauramos la base de datos:
Una vez restaurada, podemos ir al principal y iniciar la configuración del Mirror. Vamos a Databases, seleccionamos la base de datos en cuestión, botón derecho y clickamos “Mirror”. Nos aparece una segunda ventana, clickamos “Configure Security”. Nos aparece un Wizard que, básicamente, nos pide las credenciales necesarias para poder conectarnos a los dos SQL SERVER, el Principal y el Mirror. Decimos que no, a la opción de “Witnees”, en español, testigo.
Si todo ha ido bien, sólo nos falta iniciar el mirroring entre ambos servidores. Clickamos “Start Mirroring”. El mensaje que nos muestre en “Status” ha de ser, al poco de unos minutos, “Synchronized: the databases are fully synchronized”.
Veremos que en el servidor de mirror, nos aparece la base de datos pero no es operativa, si intentamos ver sus propiedades nos aparecerá un error. Es normal. Volverá a pasar a modo normal cuando acabemos en algún punto el mirroring.
Monitorización
Es recomendable monitorizar en ambos el tiempo de CPU y añadir algunos Perf Counters según el rol:
Perfmon Counters
Transaction Delay es uno de los contadores a monitorizar, nos muestra cuanto tardan las transacciones en ser “comprometidas” (to be committed). Si este contador crece, puede haber un problema en la red o en el espejo. Podría llegar a haber una degradación en el servicio que afectase a los usuarios del principal.
Otro contador a monitorizar en el principal, es el Log Send Queue KB, que muestra cuanto log no ha sido enviado al espejo. Este contador puede aumentar fácilmente, en casos especiales como una reconstrucción de un índice (un montón de tráfico de log en un corto período de tiempo). Si este valor aumenta demasiado puede suponer un problema en el caso de el principal sufriese un problema grave, ya que, muchas transacciones no se habrían realizado en el espejo.
Desde la perspectiva del mirror, el Redo Queue KB es el contador principal. Muestra cuantos KB han sido recibidos en el mirror pero no aplicados todavía en la base de datos. Es fácil deducir los problemas resultantes de esto. Este contador es importante ya que nos muestra cuanto va por detrás el espejo del principal.
Vistas
database_mirroring contiene información sobre todos los espejos configurados y el estado actual, dm_db_mirroring_connections tiene información sobre el tráfico experimentado por el principal-mirror.
Links
http://www.jimmcleod.net
http://technet.microsoft.com/
http://www.microsoft.com
http://technet.microsoft.com/
http://www.improve.dk/blog/2008/03/23/sql-server-mirroring-a-practical-approach