Procedimento de Configuração Database Mirroring SQL Server 1
Sumário 1. Histórico do Documento 3 2. Introdução 4 3. Requisitos Mínimos 4 4. Modos de operação do Database Mirroring 5 5. Configurando o Database Mirroring 6 5.1 Configurando as instâncias para conexões de saída usando um Certificado de Segurança 6 5.2 Configurando as instâncias para conexões de entrada usando um Certificado de Segurança 8 6. Configurando a sessão de Database Mirroring para um Database 9 6.1 Inicialização do database 9 6.2 Configurando os parceiros da sessão de Database Mirroring 10 6.3 Objetos Adicionais 11 6.4 Monitorando o Database Mirroring 11 7. FailOver Manual 13 7.1 Diagrama Simplificado do Procedimento 13 7.2 Alternativas para FailOver Manual 14 7.2.1 Forçando o Serviço com possível perda de informações 14 7.2.2 Utilizando um Backup do Transaction Log para evitar a perda de informações 15 8. FailBack Manual 16 8.1 Alternativas para o FailBack Manual 16 8.1.1 Recriando a sessão do Database Mirroring 16 8.1.2 Restabelecendo a sessão do Database Mirroring após forçar o serviço 18 2
1. Histórico do Documento Data Histórico 22/10/2011 Criação do documento 3
2. Introdução Este documento descreve a configuração do Database Mirroring entre 2 instâncias SQL Server em servidores distintos. Estes servidores devem preferencialmente estar no mesmo domínio. No entanto, para tornar a aplicação deste documento mais abrangente, o procedimento de configuração aqui descrito foi criado de forma que também poderá ser utilizado para a configuração do Database Mirroring entre servidores que encontram-se em domínios diferentes, sem relação de confiança entre eles, ou servidores que sequer pertencem a um domínio. A complexidade técnica envolvida na implementação deste processo não é discutida em detalhes neste documento. São apresentados os passos necessários para concluí-lo com sucesso, bem como uma breve explicação de alguns termos e conceitos. O procedimento de configuração descrito neste documento será realizado utilizando somente comandos Transact-SQL. Não será abordada a configuração através de interfaces gráficas. A comunicação entre as 2 instâncias pode ocorrer através de um link compartilhado com outros processos. Aliado ao fato de que os servidores podem estar em domínios diferentes, ou não pertencerem a nenhum domínio, isto constitui um risco para a segurança das informações. Portanto, este documento contempla também os passos necessários para garantir a encriptação dos dados transferidos entre os servidores. 3. Requisitos Mínimos O Database Mirroring funciona entre servidores 32-Bit e 64-Bit, sem restrições. Em todas as sessões de Database Mirroring, só podem haver 2 instâncias SQL Server envolvidas, uma no servidor principal e outra no servidor mirror. Ele é suportado a partir do SQL Server 2005 Service Pack 1 para as edições Standard e Enterprise. As 2 instâncias devem usar a mesma edição. Os dois servidores devem possuir a mesma estrutura de diretórios onde são armazenados os datafiles (MDF) e logfiles (LDF), inclusive em relação as letras dos drives. Em uma situação onde um novo datafile ou logfile é criado no database no servidor principal, esta operação será repetida no database no servidor mirror. Se no mirror não houver a mesma estrutura de diretórios e letras dos drives, esta operação irá falhar e o database perderá o sincronismo, fazendo com que a sessão de Database Mirroring tenha de ser reconfigurada. É recomendado que o tráfego das sessões de Database Mirroring entre o servidor principal e o servidor mirror ocorram através de uma interface de rede dedicada em cada servidor, conectadas por um cabo crossover. Em ambientes virtuais ou quando há teaming entre interfaces de rede, isto não é possível, mas é recomendado que nestes casos seja utilizada uma VLAN diferente da que é utilizada pelos aplicativos e usuários na conexão às instâncias. 4
4. Modos de operação do Database Mirroring O Database Mirroring pode operar em 2 modos: síncrono e assíncrono. Há também a possibilidade do uso de um terceiro servidor no processo, chamado Witness. Este servidor é utilizado somente em conjunto com o modo síncrono, para failover automático. Este cenário não será abordado neste documento. O modo assíncrono (high-performance mode) é suportado apenas na edição Enterprise. Neste modo, o COMMIT das transações ocorre no servidor principal e então são transferidas para o servidor mirror. Por este motivo, oferece maior desempenho no servidor principal, mas há o risco de ocorrer atraso no sincronismo e perda de informações no processo de failover. Este modo é recomendado especialmente quando o link entre os servidores não oferece desempenho satisfatório. O modo síncrono (high-protection mode) é suportado nas edições Standard e Enterprise. Neste modo, o COMMIT das transações ocorre sempre nos 2 servidores. Isto pode adicionar latência nas transações, diminuindo o desempenho no servidor principal. No entanto, o sincronismo em tempo real é garantido entre o database no servidor principal e o database no servidor mirror. Este modo é recomenado especialmente quando há um link direto entre os servidores, por interfaces de rede dedicadas ou em uma VLAN diferente da que é utilizada pelos aplicativos e usuários na conexão às instâncias. 5
5. Configurando o Database Mirroring O Database Mirroring deve ser configurado em cada instância, antes que uma sessão de Database Mirroring possa ser configurada para os databases. Para garantir a segurança das informações no tráfego através de links compartilhados, é importante que seja utilizado um certificado de segurança para autenticação e transferência de dados através dos End Points, especialmente se os servidores não estiverem no mesmo domínio ou não estiverem em nenhum domínio. Este procedimento é descrito a seguir. 5.1 Configurando as instâncias para conexões de saída usando um Certificado de Segurança Execute o seguinte procedimento no servidor principal: No database master, crie uma MASTER KEY, informando uma senha forte no parâmetro PASSWORD: Use Master; CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'senhaforte'; Execute um Backup da MASTER KEY (especifique o caminho do arquivo). informando uma senha forte no parâmetro PASSWORD. Por questões de segurança, esta senha não deve ser a mesma utilizada na criação da MASTER KEY: Use Master; BACKUP MASTER KEY TO FILE = 'C:\Mirroring_Principal_Master_Key.key' ENCRYPTION BY PASSWORD = 'senhaforte'; Crie um certificado que será utilizado no End Point do Database Mirroring: Use Master; CREATE CERTIFICATE Mirroring_Principal WITH SUBJECT = 'Mirroring Principal Certificate'; Crie um End Point para o Database Mirroring, utilizando o certificado. Certifique-se de que a porta 5022 está liberada no Firewall para entrada e saída no protocolo TCP. Se preferir, utilize outra porta: CREATE ENDPOINT Mirroring STATE = STARTED AS TCP ( LISTENER_PORT = 5022, LISTENER_IP = ALL ) FOR DATABASE_MIRRORING ( AUTHENTICATION = CERTIFICATE Mirroring_Principal, ENCRYPTION = REQUIRED ALGORITHM AES, ROLE = ALL); Execute um Backup do certificado (especifique o caminho do arquivo): BACKUP CERTIFICATE Mirroring_Principal TO FILE = 'C:\Mirroring_Principal_Certificate.cer'; Copie, de forma segura, o Backup do certificado para o servidor mirror. Mantenha a senha da MASTER KEY, o Backup da MASTER KEY e sua senha, e o Backup do certificado em um local seguro, pois eles serão necessários caso seja necessário realizar uma reconfiguração no futuro. 6
Em seguida, execute o seguinte procedimento no servidor mirror: No database master, crie uma MASTER KEY, informando uma senha forte no parâmetro PASSWORD: Use Master; CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'senhaforte'; Execute um Backup da MASTER KEY (especifique o caminho do arquivo). informando uma senha forte no parâmetro PASSWORD. Por questões de segurança, esta senha não deve ser a mesma utilizada na criação da MASTER KEY: Use Master; BACKUP MASTER KEY TO FILE = 'C:\Mirroring_Mirror_Master_Key.key' ENCRYPTION BY PASSWORD = 'senhaforte'; Crie um certificado que será utilizado no End Point do Database Mirroring: Use Master; CREATE CERTIFICATE Mirroring_Mirror WITH SUBJECT = 'Mirroring Mirror Certificate'; Crie um End Point para o Database Mirroring, utilizando o certificado. Certifique-se de que a porta 5022 está liberada no Firewall para entrada e saída no protocolo TCP. Se preferir, utilize outra porta: CREATE ENDPOINT Mirroring STATE = STARTED AS TCP ( LISTENER_PORT = 5022, LISTENER_IP = ALL ) FOR DATABASE_MIRRORING ( AUTHENTICATION = CERTIFICATE Mirroring_Mirror, ENCRYPTION = REQUIRED ALGORITHM AES, ROLE = ALL); Execute um Backup do certificado (especifique o caminho do arquivo): BACKUP CERTIFICATE Mirroring_Mirror TO FILE = 'C:\Mirroring_Mirror_Certificate.cer'; Copie, de forma segura, o Backup do certificado para o servidor principal. Mantenha a senha da MASTER KEY, o Backup da MASTER KEY e sua senha, e o Backup do certificado em um local seguro, pois eles serão necessários caso seja necessário realizar uma reconfiguração no futuro. 7
5.2 Configurando as instâncias para conexões de entrada usando um Certificado de Segurança Execute o seguinte procedimento no servidor principal: Crie um login que será utilizado para o servidor mirror conectar-se, informando uma senha forte no parâmetro PASSWORD : USE master; CREATE LOGIN mirroring_mirror WITH PASSWORD = 'senhaforte'; Crie um usuário para este login: USE master; CREATE USER mirroring_mirror_user FOR LOGIN mirroring_mirror; Associe o certificado criado no servidor mirror com o usuário (especifique o caminho do arquivo): CREATE CERTIFICATE Mirroring_Mirror_Certificate AUTHORIZATION mirroring_mirror_user FROM FILE = 'C:\Mirroring_Mirror_Certificate.cer' Conceda a permissão CONNECT no login, para o Endpoint do servidor mirror: GRANT CONNECT ON ENDPOINT::Mirroring TO mirroring_mirror; Em seguida, execute o seguinte procedimento no servidor mirror: Crie um login que será utilizado para o servidor principal conectar-se, informando uma senha forte no parâmetro PASSWORD : USE master; CREATE LOGIN mirroring_principal WITH PASSWORD = 'senhaforte'; Crie um usuário para este login: USE master; CREATE USER mirroring_principal_user FOR LOGIN mirroring_principal; Associe o certificado criado no servidor principal com o usuário (especifique o caminho do arquivo): CREATE CERTIFICATE Mirroring_Principal_Certificate AUTHORIZATION mirroring_principal_user FROM FILE = 'C:\Mirroring_Principal_Certificate.cer' Conceda a permissão CONNECT no login, para o Endpoint do servidor mirror: GRANT CONNECT ON ENDPOINT::Mirroring TO mirroring_principal; 8
6. Configurando a sessão de Database Mirroring para um Database 6.1 Inicialização do database Cada sessão de Database Mirroring é configurada individualmente, para cada database. Antes de iniciar a sessão do Database Mirroring entre as 2 instâncias, o database deverá ser inicializado na instância do servidor mirror com o Backup Full mais atual. Também será necessário um Backup do Transaction Log, que deve ser executado após o Backup Full. Este procedimento é descrito a seguir. Execute o seguinte procedimento no servidor principal: Configure o database para utilizar Full Recovery Model: ALTER DATABASE databasename SET RECOVERY FULL Execute um Backup Full do database (especifique o caminho do arquivo): BACKUP DATABASE databasename to disk = 'c:\databasename.bak' WITH FORMAT Execute um Backup do Transaction Log do database (especifique o mesmo nome de arquivo do Backup Full): BACKUP LOG databasename TO DISK = 'c:\databasename.bak' WITH NOINIT Copie o arquivo databasename.bak para um disco local do servidor mirror, da forma que oferecer a maior rapidez. Verifique o nome lógico (coluna name) e físico (coluna filename) de cada um dos arquivos do database, e copie estes nomes: USE databasename; exec sp_helpfile; Transações serão acumuladas no Transaction Log do database no servidor principal enquanto a cópia é realizada, e estas transações só começarão a ser enviadas ao servidor mirror quando a sessão do Database Mirroring for iniciada para o database. Quanto mais tempo o processo demorar para ser concluído, mais transações irão se acumular no servidor principal, e mais tempo levará a sincronização entre os servidores quando a sessão do Database Mirroring for iniciada. Concluída a cópia, execute o seguinte procedimento no servidor mirror: Restaure o Backup Full com a opção NORECOVERY. Especifique o caminho de cada arquivo MDF e LDF anotados anteriormente, que devem ser idênticos aos do servidor principal. Caso o database possua mais de dois arquivos, você deve incluir uma opção MOVE no comando abaixo para cada arquivo adicional. O database deve possuir exatamente o mesmo nome utilizado no servidor principal: RESTORE DATABASE databasename FROM DISK = 'c:\databasename.bak' WITH FILE = 1, NORECOVERY, MOVE 'nome_logico_do_mdf' TO 'c:\databasename.mdf', MOVE 'nome_logico_do_ldf' TO 'c:\databasename_log.ldf' Restaure o Backup do Transaction Log com a opção NORECOVERY (especifique o mesmo nome de arquivo do Backup Full): RESTORE LOG databasename FROM DISK = 'c:\databasename.bak' WITH FILE = 2, NORECOVERY 9
6.2 Configurando os parceiros da sessão de Database Mirroring Após a inicialização do database, o próximo passo é iniciar a sessão de Database Mirroring entre o database no servidor principal e o database de mesmo nome no servidor mirror. Este procedimento é também chamado de Configuração dos Parceiros da Sessão. Execute o seguinte procedimento no servidor mirror: Configure o database no servidor principal como um parceiro do database no servidor mirror informando o nome do database, o FQDN ou IP estático do servidor principal em <principal_address> e em <port>, o número da porta utilizada na criação do End Point no servidor principal: ALTER DATABASE databasename SET PARTNER = 'TCP://<principal_address>:<port>'; Em seguida, execute o seguinte procedimento no servidor principal: Configure o database no servidor mirror como um parceiro do database no servidor principal informando o nome do database, o FQDN ou IP estático do servidor mirror em <mirror-address> e em <port>, o número da porta utilizada na criação do End Point no servidor mirror: ALTER DATABASE databasename SET PARTNER = 'TCP://<mirror_address>:<port>'; Na edição Standard, o modo de execução é síncrono e selecionado automaticamente. Se você estiver usando a edição Enterprise, configure a sessão de Database Mirroring para executar no modo desejado. Você pode escolher entre os modos síncrono (SAFETY FULL) ou assíncrono (SAFETY OFF), dependendo dos seus requisitos: ALTER DATABASE databasename SET PARTNER SAFETY FULL; A sessão do Database Mirroring para o database será iniciada, e começará a sincronização do database no servidor principal com o database no servidor mirror. Após a configuração da sessão, é importante que o Backup do Transaction Log seja configurado para executar regularmente no database no servidor principal, pois o Database Mirroring não irá expurgar automaticamente do Transaction Log as transações já transferidas ao servidor mirror, havendo o risco do arquivo crescer indefinidamente, até que seja tomado todo o espaço disponível em disco. 10
6.3 Objetos Adicionais Cada sessão de Database Mirroring é configurada individualmente, para cada database. Objetos externos ao database não são sincronizados entre as instâncias. Portanto, a sessão não contempla a sincronização dos seguintes objetos, que deverão ser transferidos e sincronizados manualmente entre as instâncias: Logins SQL Agent Jobs, Alerts e Operators SQL Server Integration Services Packages Support databases (outros databases utilizados como apoio ao database em mirror) Linked Servers Backup Devices Maintenance Plans Configurações do Database Mail Configurações do Distributed Transaction Coordinator Entre outros... 6.4 Monitorando o Database Mirroring O monitoramento do processo pode ser feito através do SQL Server Management Studio. Siga o seguinte procedimento no servidor principal: Clique com o botão direito do mouse no database em questão. Selecione Tasks > Launch Database Mirroring Monitor. Clique em Register Mirrored Database. Informe a instância do SQL Server, e conecte-se a ela clicando no botão Connect. Serão mostrados todos os databases que possuem sessão de Database Mirroring nesta instância. Selecione o database que será registrado no Monitor, e clique em OK. O Monitor mostra diversas informações de status sobre o database, como a transação mais antiga ainda não transferida, sincronismo entre o servidor principal e mirror, entre outras. Através do Monitor, é possível acompanhar o processo, e saber se há algum problema na transferência de dados entre os servidores. Outro método, mais simplificado, de verificar o status do Database Mirroring para o database: Clique com o botão direito do mouse no database em questão. Selecione Tasks > Mirror. Observe o campo Status. São estes os tipos de estados possíveis: SYNCHRONIZING: Transações do Transaction Log estão sendo enviadas para o servidor mirror, que está aplicando estas modificações no database. SYNCHRONIZED: Quando o servidor mirror recebe as transações mais atuais do servidor principal, e aplica estas modificações no 11
database. Este estado permanece enquanto há esta condição de sincronismo na comunicação e envio constante de transações do Transaction Log do servidor principal para o mirror, e enquanto as modificações estão sendo aplicadas no database. Note que, em High- Performance Mode, a transferência de dados é assíncrona, e portanto o servidor principal não espera que as modificações sejam aplicadas no servidor mirror para então aplicá-la no servidor principal. Por isso este modo é mais recomendado quando a comunicação entre os servidores ocorre por um link compartilhado com outros processos. No entando, pode haver perda de informações caso o servidor principal fique indisponível, mesmo que no momento da falha, o estado seja SYNCHRONIZED. SUSPENDED: Quando a sessão de Mirroring foi pausada pelo administrador, ou quando o database em mirror não está disponível no servidor mirror. Neste caso, transações não estão sendo enviadas do servidor principal para o servidor mirror. DISCONNECTED: O servidor principal perdeu a comunicação com o servidor mirror. Se o estado permanece em SYNCHRONIZING constantemente, há uma contenção no servidor principal, no servidor mirror, ou no link entre eles. Muitas transações estão sendo executadas no servidor principal, ou o servidor mirror está recebendo estas transações, mas está demorando demais para aplicá-las no database. Outra possibilidade é uma contenção no link de comunicação entre os servidores, e as transações demoram a ser enviadas. Alguns contadores estão disponíveis para monitoramento do Database Mirroring, e são expostos pelo SQL Server ao sistema operacional para serem monitorados por ferramentas, através de comandos WMI, ou mesmo através do Performance Monitor do Windows. Estes mesmos contadores estão disponíveis para a configuração de alertas no SQL Server Agent, para envio de notificações por email a um operador quando ocorrerem situações de atraso no sincronismo entre os databases. 12
7. FailOver Manual 7.1 Diagrama Simplificado do Procedimento Procedimento para FailOver Manual do database Servidor Principal Instância está disponível? Sim Independente do database estar online ou não, tente efetuar o Backup do Transaction Log Conseguiu efetuar o Backup do Transaction Log? Sim Copie o Backup do Transaction Log para o disco local do Servidor Mirror Aplicativos Servidor Mirror Servidor Mirror (sem perda de informações) (possível perda de informações) Não Force o Serviço na sessão de Database Mirroring Não Servidor Mirror torna-se o Servidor Principal Reconfigure os aplicativos para acesso ao database no Servidor Mirror, agora no papel de Servidor Principal Remova a sessão de Database Mirroring Restaure o Backup do Transaction Log com a opção WITH RECOVERY Reconfigure os aplicativos para acesso ao database no Servidor Mirror. Não há uma sessão de Database Mirroring 13
7.2 Alternativas para FailOver Manual As alternativas aqui apresentadas para FailOver manual, consideram sempre um cenário de indisponibilidade no servidor principal, seja total ou apenas do database. Neste cenário, há sempre o risco de perda de informações. Isto será abordado a seguir. 7.2.1 Forçando o Serviço com possível perda de informações Caso o servidor principal esteja totalmente indisponível, sendo impossível até mesmo iniciar o serviço da instância SQL Server, não haverá outra alternativa senão Forçar o Serviço no servidor mirror. Forçar o Serviço significa forçar o FailOver para o servidor mirror, transferindo a ele o papel de servidor principal, assim como a responsabilidade de servir o acesso ao database para as aplicações. Neste processo, informações podem ser perdidas, especialmente se a sessão do Database Mirroring estiver funcionando em High-Performance Mode (assíncrono), pois não há garantias de que todas as transações mais recentes foram enviadas pelo servidor principal ao servidor mirror, antes da falha ocorrer. São transações que podem ou não existir, dependendo da frequência em que o database é atualizado. O envio destas transações pelo servidor principal ocorre tão logo são incluídas no Transaction Log. Elas permanecem em uma fila, que é rapidamente gerenciada pelo SQL Server no sentido de enviá-las o mais rápido possível para o servidor mirror. Se há um problema de lentidão no link de comunicação entre os servidores, ou contenção no servidor principal, é possível que algumas transações recentes não tenham sido enviadas antes da ocorrência da falha. Logo, estas transações são perdidas se o serviço for forçado. No entanto, a vantagem deste procedimento é que o SQL Server automaticamente transfere o papel de servidor principal para o servidor mirror, e torna o database disponível imediatamente para acesso pelos aplicativos. A sessão de Database Mirroring para o database não é removida, ela é apenas suspensa, o que facilitará o FailBack mais tarde. Se as consequências detalhadas acima são aceitáveis, efetue o seguinte procedimento: Forçe o Serviço: ALTER DATABASE databasename SET PARTNER FORCE_SERVICE_ALLOW_DATA_LOSS O servidor mirror imediatamente efetuará a transição para servidor principal, e a sessão de Database Mirroring será suspensa. O database estará disponível imediatamente para acesso pelos aplicativos. 14
7.2.2 Utilizando um Backup do Transaction Log para evitar a perda de informações A outra alternativa consiste em efetuar um Backup do Transaction Log do database, no servidor principal. Não é um Backup comum do Transaction Log, e sim um Backup que tenta recuperar as transações contidas no Transaction Log, mesmo que o database esteja indisponível. Execute este procedimento apenas se as consequências de Forçar o Serviço forem inaceitáveis. Obviamente, este procedimento só poderá ser realizado se o servidor principal estiver disponível, e o serviço da instância SQL Server estiver iniciado. O procedimento considera que o database está indisponível, e não é possível recuperá-lo. No entanto, o logfile do database está disponível em seu local original. Se este procedimento for executado com sucesso, há a garantia de que todas as transações concluídas no database no servidor principal até o momento antes da falha serão transferidas para o database no servidor mirror. Execute o seguinte procedimento no servidor principal: Efetue o Backup do Transaction Log (especifique o caminho do arquivo): BACKUP LOG databasename TO DISK = 'C:\databaseName_TransactionLog_Tail.trn' WITH CONTINUE_AFTER_ERROR, NO_TRUNCATE Se ocorrerem erros na execução deste comando, o log file do database está danificado, e as transações não podem ser recuperadas. Não há outra alternativa, senão executar o procedimento para Forçar o Serviço. Se o comando executar com sucesso, copie o Backup do Transaction Log para o servidor mirror. Se o Backup do Transaction Log foi executado com sucesso e copiado para o servidor mirror, execute o seguinte procedimento no servidor mirror: Remova a sessão de Database Mirroring para o database: ALTER DATABASE databasename SET PARTNER OFF Restaure o Backup do Transaction Log e torne o database acessível para os aplicativos (especifique o caminho do arquivo): RESTORE LOG databasename FROM DISK = 'C:\databaseName_TransactionLog_Tail.trn' WITH RECOVERY O servidor mirror está agora servindo o acesso ao database, mas como um database exposto, ou seja, sem uma sessão de Database Mirroring configurada. Se o servidor principal original se tornar novamente disponível, assim como o database neste servidor, haverão 2 cópias disponíveis do database, uma em cada servidor. É importante que os aplicativos não tenham acesso ao database no servidor principal original. 15
8. FailBack Manual O FailBack Manual ocorrerá apenas quando o servidor principal original estiver novamente disponível. O procedimento a ser aplicado depende da forma como ocorreu a indisponibilidade neste servidor, e qual procedimento foi adotado para o FailOver Manual. 8.1 Alternativas para o FailBack Manual 8.1.1 Recriando a sessão do Database Mirroring Independente do procedimento de FailOver Manual que foi executado, se a sessão de Database Mirroring foi removida para o database tanto devido ao procedimento executado ou devido a reinstalação da instância do SQL Server no servidor principal será necessário reconfigurar a sessão. Se a instância do SQL Server não foi reinstalada no servidor principal, toda a configuração do Database Mirroring está intacta. Portanto, devem ser seguidos apenas os procedimentos descritos no item Configurando a sessão de Database Mirroring para um Database, invertendo os papéis dos servidores, pois neste caso o servidor mirror irá atuar no papel de servidor principal, já que é este servidor que está atuamente servindo o acesso ao database. Por outro lado, se a instância do SQL Server foi reinstalada no servidor principal, devem ser seguidos todos os seguintes procedimentos: No item Configurando o Database Mirroring, apenas os procedimentos para configuração do servidor principal, pois é necessário configurar novamente o Database Mirroring neste servidor. O Backup do novo certificado criado no servidor principal deverá ser copiado para o servidor mirror. Neste servidor, elimine o certificado de segurança atual: USE master; DROP CERTIFICATE Mirroring_Principal_Certificate; Associe o novo certificado com o usuário mirroring_principal_user (especifique o caminho do arquivo): USE master; CREATE CERTIFICATE Mirroring_Principal_Certificate AUTHORIZATION mirroring_principal_user FROM FILE = 'C:\Mirroring_Principal_Certificate.cer' Execute todos os procedimentos descritos no item Configurando a sessão de Database Mirroring para um Database, invertendo os papéis dos servidores, pois neste momento o servidor mirror está servindo o acesso ao database e portanto irá atuar no papel de servidor principal. Após a execução destes procedimentos, a sessão de Database Mirroring será estabelecida para o database, e os papéis dos servidores podem ser invertidos, forçando o serviço, conforme o procedimento descrito no item Forçando o Serviço com possível perda de informações. No entanto, este trabalho deve ser efetuado em uma parada programada, onde sejam impedidas modificações no database, para evitar possibilidade de perda de informações decorrente do procedimento. 16
Como a sessão de Database Mirroring para o database será automaticamente suspensa pelo SQL Server ao forçar o serviço, execute o seguinte procedimento em qualquer um dos 2 servidores para restabelecê-la: Restabeleça a sessão de Database Mirroring: ALTER DATABASE databasename SET PARTNER RESUME O database no servidor mirror entrará no estado SYNCHRONIZING. Dependendo do número de transações executadas durante o período em que a sessão estava suspensa, este estado pode permanecer durante algum tempo, até que todas as transações sejam enviadas pelo servidor principal ao servidor mirror, e sejam aplicadas no database no servidor mirror. Após este período, o estado mudará para SYNCHRONIZED. 17
8.1.2 Restabelecendo a sessão do Database Mirroring após forçar o serviço Se o servidor principal estiver novamente disponível, a instância do SQL Server não foi reinstalada, suas configurações não foram perdidas, e o database estiver intacto, o SQL Server automaticamente identifica que o serviço foi forçado e inverte o papel dos servidores. Portanto, o servidor mirror assumirá automaticamente o papel de servidor principal. A sessão de Database Mirroring para o database é suspensa automaticamente. Neste momento, você deve tomar uma das seguintes decisões: Restabelecer a sessão de Database Mirroring para o database, passando a transferir as transações que foram acumuladas enquanto a sessão estava suspensa, e descartando quaisquer transações armazenadas no Transaction Log que não haviam sido enviadas para o servidor mirror até o momento da falha. Remover a sessão do Database Mirroring configurada, para tornar o database On-Line no servidor principal original, e trabalhar em conjunto com o DBA no sentido de tentar recuperar estas transações a partir do Transaction Log. Esta tarefa pode consumir um tempo considerável e só deve ser realizada se a perda destas transações for inaceitável. Nenhuma destas decisões afeta a disponibilidade do database no servidor que está atualmente servindo o acesso ao database. Se decidir por restabelecer a sessão de Database Mirroring para o database, execute o seguinte procedimento em qualquer um dos 2 servidores: Restabeleça a sessão de Database Mirroring: ALTER DATABASE databasename SET PARTNER RESUME O database no servidor mirror entrará no estado SYNCHRONIZING. Dependendo do número de transações acumuladas durante o período em que a sessão estava suspensa, este estado pode permanecer durante algum tempo, até que todas as transações sejam enviadas pelo servidor principal ao servidor mirror, e sejam aplicadas no database no servidor mirror. Após este período, o estado mudará para SYNCHRONIZED. Os papéis dos servidores podem ser invertidos novamente, forçando o serviço, conforme o procedimento descrito no item Forçando o Serviço com possível perda de informações. No entanto, este trabalho deve ser efetuado em uma parada programada, onde sejam impedidas modificações no database, para evitar possibilidade de perda de informações decorrente do procedimento. Como a sessão de Database Mirroring para o database será automaticamente suspensa pelo SQL Server ao forçar o serviço, repita o procedimento aqui descrito para restabelecer a sessão. 18