INTRODUÇÃO AO MIRRORING Artur Santos [email protected].
-
Upload
nina-rayssa-palha-henriques -
Category
Documents
-
view
218 -
download
4
Transcript of INTRODUÇÃO AO MIRRORING Artur Santos [email protected].
INTRODUÇÃO AO MIRRORING
Artur [email protected]
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.