Implementación de SQL Server en modo Espejo con TestigoMiércoles, 24 de julio de 2013eManu Hola a todos, He tenido que montar un piloto para probar que tal se comporta los servidores SQL en modo espejo y añadiendo un tercer servidor que realice las tereas de testigo, para realizar la alta disponibilidad y de esta manera tener el mínimo tiempo posible el acceso a la BBDD caído. El piloto se realiza con 2 servidores de producción, y un servidor testigo. En todos los servidores se ha instalado la misma versión de sistema operativo y de MS-SQL Server: Windows Server 2008 R2 y SQL-Server 2008 R2. En el equipo de testigo, se podría haber instalado un SQLExpress 2008, ya que en ningún momento tendrá la instancia de BBDD, y simplemente recoge información de quien tiene el rol activo. Instalación de MS-SQL Aunque la instalación de SQL SERVER tiene bastantes opciones en el momento de instalar, deberemos de tener en cuenta varias indicaciones del asistente de instalación para después esté todo operativo correctamente. Deberemos de instalar .NET FrameWork 3.5.1 e iniciar el setup de instalación, pasando, como se observa en la imágen, todas las operaciones de control con “Passed”, y en el caso de tener Warning, intentar solucionarlo. En caso de tener Failed, no podríamos continuar hasta solucionar el requerimiento de instalación. Instalamos una instancia estandard de SQL SERVER. Tendremos que seleccionar las herramientas de administración. ya que será la tecnología que vamos a . para tener acceso a “SQL-SEVER Management Studio”. No olvidar seleccionar SQL Server Replication.En mi caso. es necesario la instalación de Analysis y Reporting Services. utilizar para realizar el modo espejo. realizaremos la exportación de la BBD y del fichero de log: backup database GruposM to Disk=”C:\BackupBBDD\GruposM. He generado una tabla Excel (GruposM) con información de ACLs en un recurso compartido. para realizar las pruebas.bak” with NORECOVERY. y restauraremos la BBDD y el Log. Desde el servidor en donde está ubicada la BBDD. backup Log GruposM to Disk=”C:\BackupBBDD\LogGruposM.bak” with NORECOVERY. Configuración de modo de espejo con testigo Lo primero que tenemos que realizar es un backup de la BBDD que queremos tener en alta disponibilidad.bak”. necesitamos comprobar que el modo de copia de seguridad tiene que estar en modo FULL.restore Log GruposM from Disk=”C:\BackupBBDD\LogGruposM. restore DataBase GruposM from Disk=”C:\BackupBBDD\GruposM. Copiamos el directorio en el servidor SQL que servirá de espejo (TSQL02).bak”. nos iremos al TSQL01 e inicimos el proceso de Espejo. para esto. y pulsamos en Tasks > Mirror… . Veremos que la BBDD se queda en modo Restoring…. Pulsaremos botón derecho encima de la BBDD que requiera estar en Espejo. y desde SQL SERVER Management Studio. .Pulsamos en Configuring Security e iniciamos el Wizard de configuración de seguridad. Como en nuestra solución vamos a incluir un testigo. vamos a indicar que SI lo vamos a utilizar . .Indicamos que la configuración se va a guardar tanto en los servidores principales. como en los de Espejo y marcamos la opción de Testigo. Tenemos que abrir en el Firewall de Windows el puerto 5022 en cada uno de los servidores de alta disponibilidad. . indicando el nombre del servidor y pulsando en Connect… para realizar el Logon en el SQL- . Realizamos las mismas acciones en cada uno de los servidores espejos que vamos a utilizar. cambiaremos e indicaremos el usuario SA con su respectiva contraseña.Al pulsar conectar. nos indicará que tenemos que realizar logon con un usuario. SERVER del servidor. . realizamos las mismas acciones que con un equipo de espejo. .Para el testigo. Indicar el nombre del servidor y pulsar Conectar para realizar el logon. . Esperamos a que finalic la configuración.Pulsamos en Finish del wizard que inicie la configuración de Espejo. estarán en modo (Mirror. y los servidores en estado Espejo. veremos que la BBDD está en modo (Principal. Synchronized). podremos ver como la BBDD que hemos seleccionado para que esté en alta disponibilidad. el proceso es de validación de los ficheros la BBDD.Mientras. va cambiando el estado en cada uno de los servidores espejo. Synchronized . El estado final será que en Servidor Principal. para poder configurar los servidores de espejo que tiene nuestro entorno y no perder conectividad con los datos. ./Restoring…) Provando la Alta disponibilidad Lo primero que deberemos hacer es bajarnos el Cliente Nativo para SQL-Server. En caso de utilizar el driver ODBC de SQL Server del sistema. y en caso de Failover. sólo podremos indicar 1 servidor SQL para realizar la conexión. en mi caso para SQL-Server 2008. deberemos configurar el ODBC para que apunte al otro servidor SQL (o crear 2 origenes ODBC). Indicaremos información descriptiva del origen de datos que vamos a crear. . y cual es el servidor principal del entorno. Indicamos cual es la BBDD que vamos a tener como predeterminada. va estar en alta disponibilidad. e informamos de igual manera del servidor de espejo que tenemos en la plataforma. . y la cual.Indicaremos que nos vamos a conectar con el usuario SA o un usuario con permisos en la BBDD. .Deberemos desmarcar la opción de Adjuntar nombre del archivo de la base de datos. Pulsamos a finalizar para acabar la configuración del enlace ODBC. mientras que en el registro superior. en la imagen. deberemos de comprobar. que los datos son correctos (previamente han sido . el origen de datos que vamos a utilizar como alta disponibilidad. tenemos marcada en color rojo. tendríamos el generado con el driver SQLServer del sistema.Como vemos. Provando la alta disponibilidad Al abrir unos Access 2007 para probar el acceso a datos de alta disponibilidad y realizar el Failover. que no nos daría la posibilidad de realizar la acciones de Alta disponibilidad. Y a continuación probaremos el Filover y sin cerrar el access .configurados en el ODBC del sistema). volveremos a lanzar la consulta. Realizamos una consulta a la BBDD. . para comprobar que podemos explotar los datos: SELECT * FROM dbo_tabla Where dbo_tabla.INHERIT=”NO”. volveremos a abrirlo (para que el driver ODBC sepa que tiene que cambiar de servidor origen) y podremos continuar con la tarea. sin tener que reiniciar el enlace de datos. En otras aplicaciones como puede ser SharePoint.Nos indicará que se ha perdido la conexión a la BBDD. ya que los datos estaran en linea. . Cerraremos Access. es capaz de comprobar si el servidor ha cambiado de estado y el rol de Servidor Principal ha cambiado. que sería posible ejecutar el Servidor Testigo sobre un servidor SQL Server 2005 Express en una máquina separada de los Servidores Principal y Espejo (más adelante se detallan los distintos roles de una topología de Database Mirroring) Los roles disponibles son los siguientes: o Servidor Principal. Sin embargo. pues éste es quién monitorizará los Servidores Principal y Espejo partícipes de una Sesión de Espejo (Mirror Session) con el objetivo de asignar el papel de Principal al servidor Espejo en caso de una caída de servicio o pérdida del primero (es . ni Express. si deseamos que nuestra solución de Database Mirroring ofrezca recuperación automática ante fallos (automatic failover). entonces sí será necesario implementar un Servidor Testigo (Witness Server). Sin embargo. 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. Es decir. Mantiene la copia activa de la base de datos (base de datos principal). No es obligatorio o necesario implementar un Servidor Testigo (Witness) en una solución de Database Mirroring. Se trata de un elemento opcional. la Instancia que realice el papel de Servidor Testigo (Witness). y aplica todas las transacciones enviadas por el Servidor Principal. de tal modo. por lo tanto. o Servidor Espejo (Mirror). Database Mirroring sólo está disponible en las ediciones SQL Server 2005 Enterprise y Developer (actualizado 24/07/2009: en la Standard también). Mantiene una copia de la base de datos principal (base de datos espejo o mirror database).Tips SQL Server – Espejado de Base de Datos – Mirroring 15 de junio de 2012 en 1:19 | Publicado en SQL Server | Deja un comentario Etiquetas: SQL Server Database Mirroring es una tecnología de Alta Disponibilidad basada en un modo de funcionamiento Activo / Pasivo. se ofrece el servicio a los usuarios. no podremos utilizar Database Mirroring en SQL Server 2005 Workgroup. puede ser de cualquier edición de SQL Server 2005. Todas las transacciones son enviadas al Servidor Espejo antes de aplicarlas en la base de datos principal. o Servidor Testigo (Witness). manteniendo sincronizada la base de datos espejo. a través de la cual. el Servidor Espejo tiene que terminar las transacciones encoladas antes de poder levantarse como Servidor Principal. En caso de una caída o pérdida del Servidor Espejo. manteniéndose así el servicio). En este modo de funcionamiento. el Servidor Principal no se verá afectado. no requiere de grandes recursos. Aqui un poco la introduccion sobre este tema que estare ahondando en los proximos post .decir. por lo cual. la base de datos principal dejará de estar activa. Las transacciones son aplicadas de forma síncrona a las base de datos principal y espejo. Las transacciones son aplicadas de forma síncrona a las base de datos principal y espejo. no es posible la existencia de pérdida de datos. Sin embargo. la base de datos principal se mantendrá activa. se asignará el papel de Principal al Servidor Espejo. potenciales pérdidas de datos). no utiliza un Servidor Testigo (Witness). En caso de una caída o pérdida del Servidor Espejo. un mismo servidor puede actuar como Servidor Testigo (Witness) para múltiples sesiones de espejo. sin pérdida de rendimiento. Las transacciones son aplicadas de forma asíncrona a la base de datos espejo. En caso de una caída o pérdida del Servidor Espejo. en caso de caída del Servidor Principal. o Modo de Alta Protección (síncrono y sin testigo). gracias al cual es posible la recuperación automática ante fallos (automatic failover) o conmutación automática de roles. y además. Requiere de un Servidor Testigo (Witness) ubicado sobre una tercera máquina (que no sea ni el Servidor Principal ni el Servidor Espejo). Database Mirroring ofrece tres modos de funcionamiento: o Modo de Alta Disponibilidad (síncrono y con testigo). la recuperación ante fallos se realiza de forma manual (manual failover). ofreciendo mejor rendimiento que los anteriores modos de funcionamiento. hablando de conmutación forzada (es decir. En caso de fallo del Servidor Principal durante el envío de transacciones. al haber perdido el Quorum. cambio de roles sin comprobación de datos escritos en el servidor espejo). El trabajo realizado por el Servidor Testigo (Witness) no es muy intenso. Por supuesto también es posible la recuperación manual ante fallos (manual failover) o conmutación manual de roles. o Modo de Alto Rendimiento (asíncrono y sin testigo). Evidentemente. pero pagando como precio la existencia de posibles pérdidas de transacciones (y en consecuencia. pero la recuperación ante fallos se realiza de forma manual (manual failover).
Report "Implementación de SQL Server en Modo Espejo Con Testigo"