INTRODUÇÃO AO MIRRORING

Artur Santosartur.santos@rumos.pt

Quem sou eu.....

Formador Sénior e Consultor na RumosSQL Server desde a versão 6.5Autor de diversas workshops e webcasts para a Microsoft

Agenda

O que é o Database MirroringVantagens e DesvantagensImplementação de uma Base de Dados em MirrorSegurançaBest-PracticesConclusã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

Operating Mode Transaction Safety Witness StateHigh Performance OFF NULL

High Safety (no Auto) FULL NULL

High Safety (Auto) FULL CONNECTED

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-TextNã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

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.

DemoMirroring via Transact-SQL

Segurança

Segurança

ENDPOINT ENCRYPTIONIntegração com Transparent Data Encryption (TDE)

ENDPOINT Encryption

Pode usar os Algoritmos: RC4, RC4-128, AES, AES-128Recomendado AES. AES-128Encription (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 KEY2. Na Base de Dados Master criar um CERTIFICADO3. Na Base de Dados a pôr em Mirror, recriar a

Encryption Key encriptada pelo certificado.4. Activar a encriptação5. 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.

DemoMirror 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 - 128 (mais lento, mas mais poderoso) – SQL 2012Atenção às threads de CPU utilizadas extra para o Mirror.

Conclusão

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.