SQL 2005 Mirroring

sqlserverLOGO

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:

  • RecoveryModel -> FULL
  • RESTORE WITH NORECOVERY (en Options)
  • Restaurar con el mismo tipo de cotejamiento

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

  • Bytes Received/sec: El número de bytes recibidos del otro servidor, por segundo
  • Bytes Sent/sec: El número de bytes enviados al otro servidor, por segundo
  • Log Bytes Received/sec: El número de bytes de log recibidos del principal, por segundo
  • Log Bytes Sent/sec: El número de bytes de log enviados al mirror, por segundo
  • Log Send Queue KB: El número de kilobytes de log que no han sido enviados al mirror
  • Pages Sent/sec: El número de páginas de log transaccionales por segundo
  • Receives/sec: El número de mensajes de mirroring recibidos por segundo
  • Redo Bytes/sec: The number of bytes of log rolled forwards per second on the mirror
  • Redo Queue KB: El número de bytes  de log transaccional que permanecen en cola para ser aplicados en el mirror
  • Send/Receive: Ack Time
  • Sends/sec: Número de mensajes de mirroring enviados por segundo
  • Transaction Delay: El retraso mientras el mirror intenta hacer un commit de la transacción

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

  • sys.database_mirroring
  • sys.database_mirroring_endpoints
  • sys.database_mirroring_witnesses
  • sys.dm_db_mirroring_connections

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

Leave a Reply

Your email address will not be published. Required fields are marked *