INTRODUÇÃO AO MIRRORING Artur Santos

Quem sou eu..... Formador Sénior e Consultor na Rumos SQL Server desde a versão 6.5 Autor de diversas workshops e webcasts para a Microsoft

Agenda O que é o Database Mirroring Vantagens e Desvantagens Implementação de uma Base de Dados em Mirror Segurança Best-Practices Conclusão

O que é o Database Mirroring

O que é o Database Mirror Um dos principais problemas aplicacionais é garantir a disponíbilidade da Base de Dados. O Database Mirroring providencia um Hot/Warm Stand- By, ao nível da Base de Dados. Ao contrário de Log Shipping que transfere Backups de Log INTEIROS entre Bases de Dados, o Mirror transfere streams de registos de log entre Bases de Dados. O Database Mirror aplica TODAS as alterações feitas na Base de Dados de origem, na Base de Dados de Destino. Em Mirror existem 2 cópias de cada Base de Dados, onde somente uma delas é disponíbilizada aos clientes

O que é o Database Mirror (Conceitos) PRINCIPAL SERVER - O servidor que tem a Base de Dados Principal. MIRROR SERVER – O servidor que contém a cópia da Base de Dados Principal. WITNESS SERVER – (Opcional) Este Servidor permite efectuar o Failover Automático (Hot Stand By) da(s) Base(s) de Dado(s). SEND QUEUE – Queue existente no Transaction Log do Principal que guarda as alterações a enviar para o Mirror.

O que é o Database Mirror (Conceitos) REDO QUEUE – Queue existente no Transaction Log do Mirror que guarda as alterações ainda não efectuadas. ENDPOINT – Objecto de SQL Server que permite a comunicação de rede, (pode ser encriptado). FAILOVER – Mecanismo que permite ao SQL Server “trocar” para a Base de Dados de Mirror em caso de falha da Principal.

Modos de Operação

Vantagens e Desvantagens

Vantagens Mais robusto que o Log Shipping, pode funcionar de modo síncrono para evitar perca de dados. Failover automático, tanto do lado Servidor como do lado cliente. Encriptação automática de comunicações. Suporta Full-Text Não requer Hardware especial. (Menos Custos)

Desvantagens Em funcionamento assíncrono há possível perca de dados. Master, MSDB, TempDB e Model não aceitam Mirror. Cada Base de Dados só pode ter 1 Mirror. A Base de Dados em Mirror não está disponível para utilização, (embora se possa criar um Snapshot desta para acesso Read-Only). Funciona ao nível da Base de Dados, e não do Servidor. O Failover Automático, pode não ser indicado para aplicações que utilizam várias Bases de Dados (sem código extra no desenvolvimento).

Implementação de uma Base de Dados em Mirror

1. Colocar a Base de Dados em Full Recovery Mode. 2. Fazer um Backup Integral e do Transaction Log. 3. Restaurar os Backups em NO RECOVERY Mode. 4. Criar os ENDPOINTS nos Servidores. 5. Adicionar os servidores ao Mirror e iniciar o processo.

Demo Mirroring via Transact-SQL

Segurança

Segurança ENDPOINT ENCRYPTION Integração com Transparent Data Encryption (TDE)

ENDPOINT Encryption Pode usar os Algoritmos: RC4, RC4-128, AES, AES-128 Recomendado AES. AES-128 Encription (DISABLED, SUPPORTED, REQUIRED) CREATE ENDPOINT endpoint_mirroring STATE = STARTED AS TCP ( LISTENER_PORT = 7022 ) FOR DATABASE_MIRRORING ( AUTHENTICATION = WINDOWS, ENCRYPTION = SUPPORTED, ALGORITHM AES, ROLE=ALL); GO

Transparent Data Encryption (TDE) 1. Na Base de Dados Master criar a MASTER KEY 2. Na Base de Dados Master criar um CERTIFICADO 3. Na Base de Dados a pôr em Mirror, recriar a Encryption Key encriptada pelo certificado. 4. Activar a encriptação 5. Fazer um Full Backup da Base de Dados. 6. Exportar a Master Key e o Certificado para ficheiros. 7. No Mirror, importar a Master Key e o Certificado. 8. Restaurar o Backup em modo NO RECOVERY. 9. Em ambos os servidores recriar os ENDPOINTS. 10. Adicionar AMBOS os Partners à sessão.

Demo Mirror a TDE Database

Best-Practices

Mirror Best-Practices Utlizar placas de rede dedicadas só para Mirror. Quanto maior a largura de banda, melhor a Performance. Atenção ao tamanho dos Logs, mesmo em pausa o Mirror consome espaço de Log, por causa das Queues. Ao utilizar encriptação, optar por AES,ou AES (mais lento, mas mais poderoso) – SQL 2012 Atenção às threads de CPU utilizadas extra para o Mirror.

Conclusão

O Database Mirror pode ser uma opção mais acessivel, numa situação de Disaster Recovery. Pode ser ainda usado como estratégia complementar de Disaster Recovery, em consonância com outras, (Clustering por exemplo), para distribuir os dados geograficamente. Compativel com o SQL Server 2012 e a nova funcionalidade de AlwaysOn.