Partilhar via


Espelhamento e Replicação de Bases de Dados (SQL Server)

Aplica-se a:SQL Server

O espelhamento de bases de dados pode ser usado em conjunto com a replicação para melhorar a disponibilidade da base de dados da publicação. O espelhamento de bases de dados envolve duas cópias de uma única base de dados que normalmente residem em computadores diferentes. Em qualquer momento, apenas uma cópia da base de dados está atualmente disponível para os clientes. Esta cópia é conhecida como base de dados principal. As atualizações feitas pelos clientes à base de dados principal são aplicadas à outra cópia da base de dados, conhecida como base de dados espelhada. O espelhamento envolve aplicar o registo de transações de cada inserção, atualização ou eliminação feita na base de dados principal na base de dados espelhada.

O failover de replicação para um espelho é totalmente suportado para bases de dados de publicações, com suporte limitado para bases de dados por subscrição. O espelhamento de bases de dados não é suportado para a base de dados de distribuição. Para informações sobre como recuperar uma base de dados de distribuição ou de subscrição sem necessidade de reconfigurar a replicação, consulte Backup e Restore Replicated Databases.

Observação

Após um failover, o espelho torna-se o principal. Neste tópico, "principal" e "espelho" referem-se sempre ao principal original e ao espelho.

Requisitos e Considerações para a Utilização da Replicação com Espelhamento de Bases de Dados

Esteja ciente dos seguintes requisitos e considerações ao utilizar replicação com espelhamento de base de dados:

  • O principal e o espelho devem partilhar um Distribuidor. Recomendamos que este seja um Distribuidor remoto, o que proporciona maior tolerância a falhas caso o Editor tenha um failover não planeado.

  • A replicação suporta espelhar a base de dados de publicações para replicação por fusão e para replicação transacional com subscritores apenas de leitura ou subscritores atualizados em fila. Atualização imediata dos Subscritores, Editoras Oracle, Editoras numa topologia peer-to-peer e republicação não são suportadas.

  • Metadados e objetos que existem fora da base de dados não são copiados para o espelho, incluindo logins, jobs, servidores ligados, e assim por diante. Se precisar dos metadados e objetos do espelho, deve copiá-los manualmente. Para mais informações, consulte Gestão de Logins e Empregos Após a Mudança de Função (SQL Server).

Configuração da Replicação com Espelhamento de Base de Dados

Configurar a replicação e o espelhamento de bases de dados envolve cinco etapas. Cada etapa é descrita com mais detalhe na secção seguinte.

  1. Configura o editor.

  2. Configurar o espelhamento da base de dados.

  3. Configure o espelho para usar o mesmo Distribuidor que o principal.

  4. Configurar agentes de replicação para no caso de falha.

  5. Adicione o principal e o espelho ao Replication Monitor.

Os passos 1 e 2 também podem ser realizados na ordem oposta.

Para configurar o espelhamento de bases de dados para uma base de dados de publicação

  1. Configure o Publicador:

    1. Recomendamos a utilização de um distribuidor remoto. Para mais informações sobre como configurar distribuição, consulte Configurar distribuição.

    2. Pode ativar uma base de dados para publicações snapshot e transacionais e/ou fundir publicações. Para bases de dados espelhadas que contenham mais do que um tipo de publicação, deve ativar a base de dados para ambos os tipos no mesmo nó usando sp_replicationdboption. Por exemplo, pode executar as seguintes chamadas de procedimento armazenado no principal:

      exec sp_replicationdboption @dbname='<PublicationDatabase>', @optname='publish', @value=true;  
      exec sp_replicationdboption @dbname='<PublicationDatabase>', @optname='mergepublish', @value=true;  
      

      Para obter mais informações sobre como criar publicações, consulte Publicar dados e objetos de banco de dados.

  2. Configurar o espelhamento da base de dados. Para mais informações, consulte Estabelecer uma Sessão de Espelhamento de Base de Dados Usando Autenticação Windows (SQL Server Management Studio) e Configurar o Espelhamento de Base de Dados (SQL Server).

  3. Configura a distribuição do espelho. Especifique o nome do espelho como o Publisher e especifique a mesma pasta Distributor e snapshot que o principal utiliza. Por exemplo, se estiver a configurar a replicação com procedimentos armazenados, execute sp_adddistpublisher no Distribuidor; e depois executa sp_adddistributor no espelho. Para sp_adddistpublisher:

    • Defina o valor do parâmetro @publisher para o nome da rede do espelho.

    • Defina o valor do parâmetro @working_directory para a pasta snapshot usada pelo principal.

  4. Especifique o nome do mirror para o parâmetro do agente -PublisherFailoverPartner. Agente Este parâmetro é necessário para que os seguintes agentes identifiquem o espelho após o failover:

    • Snapshot Agent (para todas as publicações)

    • Agente Leitor de Registo (para todas as publicações transacionais)

    • Agente Leitor de Fila (para publicações transacionais que suportam subscrições com atualizações em fila)

    • Merge Agent (para subscrições de fusão)

    • Ouvinte de replicação do SQL Server (replisapi.dll: para subscrições de fusão sincronizadas através de sincronização Web)

    • Controlo ActiveX de Mistura SQL (para subscrições de mistura sincronizadas com o controlo)

    O Agente de Distribuição e o Controlo ActiveX de Distribuição não têm este parâmetro porque não se ligam ao Publicador.

    As alterações nos parâmetros do agente entram em vigor na próxima vez que o agente é iniciado. Se o agente estiver a funcionar continuamente, deve parar e reiniciar o agente. Os parâmetros podem ser especificados nos perfis do agente e no prompt de comandos. Para obter mais informações, consulte:

    Recomendamos adicionar o -PublisherFailoverPartner a um perfil de agente e, em seguida, especificar o nome do mirror no perfil. Por exemplo, se estiver a configurar a replicação com procedimentos armazenados:

    -- Execute sp_help_agent_profile in the context of the distribution database to get the list of profiles.  
    -- Select the profile id of the profile that needs to be updated from the result set.  
    -- In the agent_type column returned by sp_help_agent_profile:   
    -- 1 = Snapshot Agent; 2 = Log Reader Agent; 3 = Distribution Agent; 4 = Merge Agent; 9 = Queue Reader Agent.  
    
    exec sp_help_agent_profile;  
    
    -- Setting the -PublisherFailoverPartner parameter in the default Snapshot Agent profile (profile 1).  
    -- Execute sp_add_agent_parameter in the context of the distribution database.  
    exec sp_add_agent_parameter @profile_id = 1, @parameter_name = N'-PublisherFailoverPartner', @parameter_value = N'<Failover Partner Name>';  
    
    -- Setting the -PublisherFailoverPartner parameter in the default Merge Agent profile (profile 6).  
    -- Execute sp_add_agent_parameter in the context of the distribution database.  
    exec sp_add_agent_parameter @profile_id = 6, @parameter_name = N'-PublisherFailoverPartner', @parameter_value = N'<Failover Partner Name>';  
    
  5. Adicione o principal e o espelho ao Replication Monitor. Para mais informações, consulte Adicionar e Remover Editores do Replication Monitor.

Manutenção de uma Base de Dados de Publicações Espelhada

Manter uma base de dados de publicações espelhada é essencialmente o mesmo que manter uma base de dados não espelhada, com as seguintes considerações:

  • A administração e monitorização devem ocorrer no servidor ativo. No SQL Server Management Studio, as publicações aparecem apenas na pasta Publicações Locais para o servidor ativo. Por exemplo, se fizer failover para o servidor espelho, as publicações são exibidas no servidor espelho e deixam de ser exibidas no servidor principal. Se a base de dados fizer failover para o espelho, poderá ser necessário atualizar manualmente o Management Studio e o Replication Monitor para que a alteração seja refletida.

  • O Monitor de Replicação exibe nós do Publisher na árvore de objetos, tanto para o primário quanto para o espelho. Se o principal for o servidor ativo, a informação de publicação é exibida apenas sob o nó principal no Monitor de Replicação.

    Se o espelho for o servidor ativo:

    • Se um agente tiver um erro, esse erro é indicado apenas no nó principal, não no nó de espelho.

    • Se o principal não estiver disponível, os nós principal e espelho exibem listas idênticas de publicações. A monitorização deve ser efetuada nas publicações sob o nó tipo espelho.

  • Ao utilizar procedimentos armazenados ou Objetos de Gestão de Replicação (RMO) para administrar a replicação no espelho, nos casos em que especifica o nome do Publisher, deve especificar o nome da instância onde a base de dados foi ativada para replicação. Para determinar o nome apropriado, use a função publishingservername.

    Quando uma base de dados de publicação é espelhada, os metadados de replicação armazenados na base de dados espelhada são idênticos aos metadados armazenados na base de dados principal. Consequentemente, para bases de dados de publicação habilitadas para replicação no principal, o nome da instância do Publisher armazenada nas tabelas do sistema no espelho é o nome do principal, não do espelho. Isto afeta a configuração e manutenção da replicação se a base de dados de publicação alternar para o espelho. Por exemplo, se estiver a configurar a replicação com procedimentos armazenados no servidor espelho após uma falha, e quiser adicionar uma subscrição pull a uma base de dados de publicação que estava ativada no principal, deve especificar o nome do principal em vez do nome do espelho para o parâmetro @publisherde sp_addpullsubscription ou sp_addmergepullsubscription.

    Se ativar uma base de dados de publicação no espelho após o failover para o espelho, o nome da instância do Publisher armazenado nas tabelas do sistema é o nome do espelho; neste caso, utilizaria o nome do espelho para o parâmetro @publisher.

    Observação

    Em alguns casos, como sp_addpublication, o parâmetro @publisher é suportado apenas para Editores não SQL Server; nestes casos, não é relevante para o espelhamento de base de dados do SQL Server.

  • Para sincronizar uma subscrição no Management Studio após um failover: sincronize as subscrições pull do Assinante e as subscrições push do Publicador ativo.

Comportamento de replicação se o espelhamento for removido

Tenha em mente as seguintes questões se o espelhamento de bases de dados for removido de uma base de dados publicada:

  • Se a base de dados de publicação no principal já não for replicada, a replicação continua a funcionar inalterada relativamente ao principal original.

  • Se a base de dados de publicação passar do principal para o espelho e a relação de espelhamento for subsequentemente desativada ou removida, os agentes de replicação não funcionarão contra o espelho. Se o principal for permanentemente perdido, desative e depois reconfigure a replicação com o mirror especificado como o Publisher.

  • Se o espelhamento da base de dados for removido completamente, a base de dados espelhada encontra-se em estado de recuperação e deve ser restaurada para se tornar funcional. O comportamento da base de dados recuperada em relação à replicação depende de a opção KEEP_REPLICATION ser especificada. Esta opção obriga a operação de restauro a preservar as definições de replicação ao restaurar uma base de dados publicada num servidor diferente daquele onde o backup foi criado. Use a opção KEEP_REPLICATION apenas quando a outra base de dados de publicações não estiver disponível. A opção não é suportada se a outra base de dados de publicações ainda estiver intacta e a replicar-se. Para mais informações sobre KEEP_REPLICATION, consulte RESTAURAR (Transact-SQL).

Comportamento do Agente Leitor de Registo

A tabela seguinte descreve o comportamento do Agente Leitor de Registo para os vários modos operacionais de espelhamento de bases de dados.

Modo de funcionamento Comportamento do Agente Leitor de Registo se o espelho não estiver disponível
Modo de alta segurança com failover automático Se o espelho não estiver disponível, o Agente Leitor de Registo propaga comandos para a base de dados de distribuição. O principal não pode executar a troca para o espelho até que este esteja novamente online e tenha todas as transações do principal.
Modo de alto desempenho Se o espelho não estiver disponível, a base de dados principal está a correr exposta (ou seja, não espelhada). No entanto, o Agente Leitor de Registo apenas replica as transações que estão confirmadas no espelho. Se o serviço for forçado e o servidor espelho assumir o papel de principal, o Agente Leitor de Registos trabalhará com o espelho e começará a captar as novas transações.

Esteja ciente de que a latência de replicação aumentará se o espelho ficar atrás do principal.
Modo de alta segurança sem failover automático Todas as transações comprometidas são garantidas a serem gravadas no disco de espelho. O Agente Leitor de Registo replica apenas as transações que estão reforçadas no espelho. Se o espelho não estiver disponível, o principal impede atividade adicional na base de dados; portanto, o Agente Leitor de Registo não tem transações para replicar.

Ver também

Replicação do SQL Server
Envio e replicação de logs (SQL Server)