Logo
  • Entries
  • Comments
  • Popular
Recent Posts
  • January 2012
  • November 2011
  • October 2011
  • September 2011
  • August 2011
  • July 2011
  • June 2011
  • May 2011
  • April 2011
  • March 2011
  • February 2011
  • January 2011
  • December 2010
  • November 2010
  • October 2010
  • September 2010
  • August 2010
  • July 2010
  • June 2010
  • May 2010
  • April 2010
  • March 2010
  • February 2010
  • January 2010
  • December 2009
  • November 2009
  • October 2009
  • September 2009
  • August 2009
  • July 2009
  • June 2009
  • May 2009
  • April 2009
  • March 2009
  • February 2009
  • January 2009
  • December 2008
  • November 2008
  • October 2008
  • September 2008
  • August 2008
  • July 2008
  • June 2008
  • May 2008
  • April 2008
  • March 2008
  • February 2008
  • January 2008
  • December 2007
  • November 2007
  • October 2007
  • July 2007
Recent Comments
  • Makendra It's always a pleasure to hear from someone with eexrpitse....
  • Rubén Ortiz Hola dependerá de varias cosas pero la respuesta sería NO. ...
  • jose miguel perea Buenos días, ¿La replicación entre maestro y esclavo es i...
  • Rubén Ortiz Si lo hacéis legal, con VMware el único problema son los cos...
  • Angel Hola, estamos valorando implementar baremetal para crear un ...
Popular Articles
  • Declaro la guerra al mosquito Tigre (35)
  • Phpbb3 - encode error converter (19)
  • MySQL - Variables básicas a configurar (17)
  • Reinicio programado Windows 2003 Server (16)
  • Plesk - Evitar el SPAM (10)
  • Home
  • Contacta
  • Hosting Linux
  • Legal
  • Sobre mí – About me

SQL 2005 Mirroring

Posted by Rubén Ortiz on Nov 20, 2009 in Windows | 0 comments

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

Click here to cancel reply.

Nube de Tags

apache bare metal benchmark cacti centos dell drupal esxi General gripe A Hardware humor IIS kayako Linux lpi lyric Lyrics memcached mysql nginx openfiler OpenVZ openx Parallels php Phpbb plesk postgresql proftpd raid SQL Server ssh svn trac ubuntu varnish Virtualizacion Virtuozzo Virtuozzo Linux Warphammer.net Windows windows 2003 wordpress zabbix

Categorias

  • 2003 Server
  • Apache 2.X
  • benchmark
  • Centos
  • Cuanto (Luser) Cabron
  • ESXi
  • General
  • Hardware
  • IIS
  • Lighttpd
  • Linux
  • Lyrics
  • MySql
  • Nginx
  • OpenVZ
  • Parallels
  • Parallels Bare Metal
  • Php
  • Phpbb
  • Plesk
  • PostgreSQL
  • Prestashop
  • Software
  • SQL SERVER
  • Ubuntu
  • Varnish
  • Virtualizacion
  • Virtuozzo
  • Virtuozzo Windows
  • VMWare
  • Warphammer.net
  • Windows
  • Wordpress

Blogroll

  • David Toribio
  • EasyCompany.es
  • Marius Duch
  • Series
  • Warphammer.net

Recursos

  • Backup Plesk9
  • CentOS 5 32 bits RPMs
  • CentOS 5 64 bits RPMs
  • Lighttpd
  • MySQL Tunner
  • OpenVZ – Panel – PROXMOX
  • OpenVZ – Panel – VTONF
  • OpenVZ Wiki
  • Parallels Virtual Automation Resources
  • Plesk 8 Docs
  • Plesk 9 Docs
  • Plesk Hacker
  • Port80 – Compression Check
  • Virtuozzo DOCS
  • Virtuozzo Lin Commands
  • Virtuozzo Win Commands
  • Virtuozzo Windows Docu

Meta

  • Log in
  • Entries RSS
  • Comments RSS
  • WordPress.org
Designed by Elegant Themes | Powered by Wordpress