SQL11 Denali: Alta Disponibilidad

RUBÉN GARRIGÓS

REL-316

Mentor –Área Motor Relacional

MCP – MCAD – MCSD – MCTS – MCT - MCITP

rgarrigos@solidq.com

α Panorama actual «preDenali»

α SQL Server «Denali» AlwaysON

Objetivos de la sesión

Panorama actual

α Clustering β Geo-clustering

α Database Mirroring β Síncrono/asíncrono

α Log Shipping

α Replicación β Transaccional

β Peer to peer replication

α Software a medida

Tecnologías disponibles

α No asumible β Clustering Replicación de cabina

β Database Mirroring Síncrono

γ Mirroring sobre cluster

β Desarrollo a medida

γ Transacciones distribuidas

α Asumible β Mirroring asíncrono

β Replicación transaccional

β Replicación peer to peer

β Log Shipping

Pérdida de transacciones

α Automático β Clustering

β Database Mirroring Síncrono

β Desarrollo a medida

γ Detección de servidor no disponible

γ La aplicación conoce los servidores secundarios

α Manual β Mirroring asíncrono

β Replicación transaccional

β Replicación peer to peer

β Log Shipping

Balanceo

α Instancia β Clustering

α Base de datos β Database Mirroring síncrono

β Database Mirroring ásíncrono

β Log Shipping

α Tabla β Replicación transaccional

β Replicación peer to peer

α Desarrollo a medida β Cualquier combinación de las anteriores

Granularidad del balanceo

α Sin uso β Clustering Cluster multi-instancia

α Solo Lectura β Replicación transaccional

β Replicación peer to peer Evitamos conflictos

β Log Shipping Standby

β Database Mirroring Database Snapshots

α Lectura/escritura β Replicación peer to peer

α Desarrollo a medida β Cualquier combinación de las anteriores

Uso de los secundarios

α Clustering β SAN

β Rendimiento

γ Replicación de cabina

γ Geoclustering

α Database Mirroring β Rendimiento

γ Síncrona vs asíncrona

α Replicación β Mantenibilidad

α Log Shipping β Almacenamiento compartido

α Desarrollo a medida β Desarrollo, mantenimiento, …

Costes

α Mezcla de alternativas β Intentar complementar las debilidades y aunar las fortalezas

β Importante tener procedimientos y scripts bien probados

β No olvidar los «accesorios»

γ Jobs

γ Permisos

γ Configuración de las instancias

α Escenario 1 β Cluster + DB mirroring async + Log Shipping

α Escenario 2 β Geo-cluster + Log Shipping

α Escenario 3 β Peer to peer

α Escenario 4 β Software de replicación + aplicación

Soluciones personalizadas

SQL Server «Denali» AlwaysON

α Solución sencilla con poco mantenimiento y eficiente

α Clustering β Redirección de clientes automática

β Política de failover flexible

α Mirroring β Failover de grupos de bases de datos

β Síncrono/asíncrono

β Compresión y encriptación

β Réplicas de solo lectura Snapshot transparente

β Reparación de páginas automática

α Log Shipping β Múltiples secundarios: 4 secundarios, 2 síncronos, 1 failover

automático

Objetivos

Múltiples réplicas

α Basados en Windows Clustering β Almacenamiento no compartido $$$

α Ping entre nodos «isAlive»

α Coordinación de failover

α Configuración y estado sincronizado entre nodos

Grupos de disponibilidad

Windows Cluster

Sincronización

del LOG Sincronización

del LOG

Montando una solución de HA completa

α Bases de datos autocontenidas (CDBs) β Información de autenticación va embebida en la base de datos

β Las tablas creadas en tempdb utilizan el collation de la BBDD

β Configuración de instancia, jobs, endpoints, etc. deberán gestionarse manualmente

α Soporte de rolling upgrades

α Grupos de disponibilidad soportados sobre instancias clusterizadas y no clusterizadas

α Soporte para Windows Server Core

α Los grupos de disponibilidad no reemplazan a clustering ni a geocluster, lo complementan

α Si reemplaza a mirroring β Por compatibilidad la configuración 1 a 1 con FailoverPartner

α No reemplaza a la replicación

Otras consideraciones

α Uno de los problemas del alta disponibilidad y la recuperación ante desastres es su coste hardware + software

β En periodos de crisis es complicado justificar un servidor completo simplemente para el eventual caso de desastre

α Maximizar la utilización de los servidores β Informes

β Procesos ETL

β Realización de backups

β Chequeos de integridad en secundarios

α Desde el punto de vista de rendimiento por licencia mejor 2+2 sockets en distintas máquinas

β Intel® Xeon® Processor E7-2870 (30M Cache, 2.40 GHz, 10C, 20T)

Secundarios activos

α Debemos configurar la réplica para que esté habilitada para lectura

α Nueva propiedad en la conexión «ApplicationIntent»

α Redirección transparente en el caso de cambio de rol al nuevo secundario

α Contención entre consultas y el thread «redo» β Se ignoran los hints de bloqueo

β Se utiliza aislamiento snapshot por defecto

α Se crean automáticamente estadísticas en tempdb β La indexación sigue teniendo que ser compartida

Secundarios solo lectura

Informes tiempo real y redirección solo lectura

α Servidor de informes β Latencia

β Rendimiento comparado con el principal

α Backups β Respaldos del principal sobre el secundario

β Restauración del backup en el principal y resincronización

α CHECKDB β Validez de esta comprobación en el secundario

Descarga del principal

Backups en servidores secundarios

Si quieres disfrutar de las mejores sesiones de

nuestros mentores de España y Latino América,

ésta es tu oportunidad.

http://summit.solidq.com/madrid/