INTRODUÇÃO AO MIRRORING
Artur Santos
[email protected]
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 StandBy, 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 State
High 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-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
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 - 128
(mais lento, mas mais poderoso) – SQL 2012
Atençã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.