Gerenciar cópias de banco de dados de caixa de correio
Em Exchange Server, você pode usar o Console de Gerenciamento do Exchange (EAC) ou o Shell de Gerenciamento do Exchange para adicionar cópias de banco de dados de caixa de correio depois que um DAG (grupo de disponibilidade de banco de dados) tiver sido criado, configurado e preenchido com membros do servidor mailbox.
Gerenciar cópias de banco de dados
Depois que várias cópias de um banco de dados forem criadas, você poderá usar o EAC ou o Shell de Gerenciamento do Exchange para monitorar a integridade e o status de cada cópia e executar outras tarefas de gerenciamento associadas a cópias de banco de dados. Algumas das tarefas de gerenciamento que você talvez precise realizar incluem a suspensão ou a retomada de uma cópia de banco de dados, a propagação de uma cópia de banco de dados, o monitoramento de cópias de banco de dados, a configuração das definições da cópia de banco de dados e a remoção da cópia de banco de dados.
Suspender e retomar cópias de banco de dados
Por uma variedade de motivos, como executar a manutenção planejada, talvez seja necessário suspender e retomar a atividade de replicação contínua para uma cópia de banco de dados. Além disso, algumas tarefas administrativas, como a semeadura, exigem que você primeiro suspenda uma cópia de banco de dados. Recomendamos que você suspenda todas as atividades de replicação quando o caminho para o banco de dados ou seus arquivos de log estiver sendo alterado. Você pode suspender e retomar a atividade de cópia de banco de dados usando o EAC ou executando os cmdlets Suspend-MailboxDatabaseCopy e Resume-MailboxDatabaseCopy no Shell de Gerenciamento do Exchange. Para obter instruções detalhadas sobre como suspender ou retomar a atividade de replicação contínua para uma cópia do banco de dados, consulte Suspender ou retomar uma cópia do banco de dados de caixa de correio.
Propagar uma cópia do banco de dados
A semente, também conhecida como atualização, é o processo no qual um banco de dados em branco ou uma cópia do banco de dados de produção é adicionado ao local da cópia de destino em outro servidor da Caixa de Correio no mesmo DAG que o banco de dados ativo. Ele se torna o banco de dados de linha de base para a cópia mantida pelo servidor.
Dependendo da situação, você pode semear um banco de dados usando um processo automático ou um processo manual iniciado. Quando uma cópia de banco de dados for adicionada, ela será propagada automaticamente, desde que o servidor de destino e o armazenamento sejam configurados corretamente. Se você quiser semear manualmente uma cópia de banco de dados e não quiser que a semente automática ocorra ao criar a cópia, você pode usar o parâmetro SeedingPostponed ao executar o cmdlet Add-MailboxDatabaseCopy .
As cópias de banco de dados raramente precisam ser resseadas após a semente inicial. No entanto, se o ressecamento for necessário ou se você quiser semear manualmente uma cópia de banco de dados em vez de ter o sistema automaticamente semeado a cópia, você terá duas opções. Você pode reutilizar um banco de dados usando o assistente Atualizar Cópia de Banco de Dados da Caixa de Correio no EAC ou usando o cmdlet Update-MailboxDatabaseCopy no Shell de Gerenciamento do Exchange. Antes de propagar uma cópia de banco de dados, você deve primeiro suspender a cópia de banco de dados de caixa de correio. Para obter etapas detalhadas sobre como propagar a cópia de um banco de dados, consulte Atualizar uma cópia de banco de dados de caixa de correio.
Após a conclusão de uma operação de propagação manual, a replicação da cópia de banco de dados de caixa de correio propagada é retomada automaticamente. Se você não quiser que a replicação seja retomada automaticamente, será possível usar o parâmetro ManualResume durante a execução do cmdlet Update-MailboxDatabaseCopy.
Escolher o que propagar
Ao executar uma operação de semente, você pode optar por semear a cópia do banco de dados da caixa de correio, o catálogo de índice de conteúdo para a cópia do banco de dados da caixa de correio ou a cópia do banco de dados e a cópia do catálogo do índice de conteúdo. O comportamento padrão do assistente de Atualização de Cópia do Banco de Dados de Caixa de Correio e do cmdlet Update-MailboxDatabaseCopy é propagar a cópia do banco de dados de caixa de correio e a cópia do catálogo de índice de conteúdo. Para semear apenas a cópia do banco de dados de caixa de correio sem sem semear o catálogo de índice de conteúdo, use o parâmetro DatabaseOnly ao executar o cmdlet Update-MailboxDatabaseCopy . Para propagar apenas a cópia do catálogo do índice de conteúdo, use o parâmetro CatalogOnly ao executar o cmdlet Update-MailboxDatabaseCopy.
Selecionar a fonte da propagação
Qualquer cópia de banco de dados íntegra pode ser usada como a origem de propagação de uma cópia adicional desse banco de dados. Isso é especialmente útil quando você tem um DAG estendido por vários locais físicos. Por exemplo, considere uma implantação do DAG com quatro membros, na qual dois membros (MBX1 e MBX2) estejam localizados em Portland, Oregon, e dois (MBX3 e MBX4) estejam em Nova York, Nova York. Um banco de dados de caixa de correio chamado DB1 está ativo em MBX1 e há cópias passivas de DB1 em MBX2 e MBX3. Ao adicionar uma cópia do DB1 para o MBX4, você tem a opção de usar a cópia no MBX3 como a origem da propagação. Fazendo isso, você evita propagar pelo link da rede de longa distância (WAN) entre Portland e Nova York.
Para usar uma cópia específica como fonte para semeadura ao adicionar uma nova cópia de banco de dados, você pode fazer o seguinte:
Use o parâmetro SeedingPostponed ao executar o cmdlet Add-MailboxDatabaseCopy para adicionar a cópia do banco de dados. Se você não usar o parâmetro SeedingPostponed , a cópia do banco de dados será explicitamente semeada usando a cópia ativa do banco de dados como a origem.
Você pode especificar o servidor de origem que deseja usar como parte do assistente Atualizar Cópia de Banco de Dados da Caixa de Correio no EAC ou usar o parâmetro SourceServer ao executar o cmdlet Update-MailboxDatabaseCopy para especificar o servidor de origem desejado para semente. No exemplo anterior, você especificaria MBX3 como o servidor de origem. Se você não usar o parâmetro SourceServer , a cópia do banco de dados será explicitamente semeada da cópia ativa do banco de dados.
Propagação e redes
Além de selecionar um servidor de origem específico para semear uma cópia de banco de dados de caixa de correio, você também pode usar o Shell de Gerenciamento do Exchange para especificar quais redes DAG devem ser usadas. Você tem a opção de substituir as configurações de compactação e criptografia da rede DAG durante a operação de semente.
Você pode especificar as redes que deseja usar para semeadura usando o parâmetro Rede ao executar o cmdlet Update-MailboxDatabaseCopy e especificar as redes DAG que deseja usar. Se você não usar o parâmetro Rede , o sistema usará o seguinte comportamento padrão para selecionar uma rede a ser usada para a operação de semeadura:
Se o servidor de origem e o servidor de destino estiverem na mesma sub-rede e uma rede de replicação tiver sido configurada incluindo a sub-rede, a rede de replicação será usada.
Se o servidor de origem e o servidor de destino estiverem em sub-redes diferentes, mesmo que uma rede de replicação contendo essas sub-redes for configurada, a rede cliente (MAPI) será usada na propagação.
Se o servidor de origem e o servidor de destino estiverem em datacenters diferentes, a rede cliente (MAPI) será usada na propagação.
No nível do DAG, as redes do DAG são configuradas para criptografia e compactação. As configurações padrão usam criptografia e compactação apenas para comunicações em sub-redes diferentes. Se a origem e o destino estiverem em sub-redes diferentes e o DAG estiver configurado com os valores-padrão para NetworkCompression e NetworkEncryption, será possível substituir esses valores usando-se os parâmetros NetworkCompressionOverride e NetworkEncryptionOverride, respectivamente, durante a execução do cmdlet Update-MailboxDatabaseCopy.
Processo de propagação
Quando você inicia um processo de semeadura usando os cmdlets Add-MailboxDatabaseCopy ou Update-MailboxDatabaseCopy , as seguintes tarefas são executadas:
As propriedades do banco de dados do Active Directory são lidas para validar o banco de dados e os servidores especificados e verificar se os servidores de origem e de destino estão executando Exchange Server, ambos são membros do mesmo DAG e que o banco de dados especificado não é um banco de dados de recuperação. Os caminhos do arquivo de banco de dados também são lidos.
As preparações ocorrem para verificações novamente propagadas a partir do serviço de replicação do Microsoft Exchange no servidor de destino.
O serviço de replicação do Microsoft Exchange no servidor de destino verifica a presença de arquivos do log de transação e do banco de dados nos diretórios de arquivos lidos pelas verificações do Active Directory na etapa 1.
O serviço de replicação do Microsoft Exchange retorna as informações de status do servidor de destino para a interface administrativa onde o cmdlet foi executado.
Se todas as verificações preliminares tiverem sido aprovadas, você será solicitado a confirmar a operação antes de continuar. Se você confirmar a operação, o processo continuará. Se um erro for encontrado durante as verificações preliminares, o erro será informado e haverá falha na operação.
A operação de propagação é iniciada no serviço de replicação do Microsoft Exchange no servidor de destino.
O serviço de replicação do Microsoft Exchange suspende a replicação do banco de dados para a cópia do banco de dados ativa.
As informações de estado do banco de dados são atualizadas pelo serviço de replicação do Microsoft Exchange para refletir um status de Propagação.
Se o servidor de destino ainda não tiver os diretórios para os arquivos do banco de dados de destino e do log, eles serão criados.
Uma solicitação para propagar o banco de dados é passada do serviço de replicação do Microsoft Exchange, no servidor de destino, para o serviço de replicação do Microsoft Exchange, no servidor de origem, usando TCP. Essa solicitação e a comunicação subsequente para a propagação do banco de dados ocorrem em uma rede do DAG configurada como uma rede de replicação.
O serviço de replicação do Microsoft Exchange no servidor de origem inicia um backup de streaming do Mecanismo de Armazenamento Extensível (ESE) por meio da interface de serviço de Armazenamento de Informações do Microsoft Exchange.
O serviço de Armazenamento de Informações do Microsoft Exchange transmite os dados do banco de dados para o serviço de replicação do Microsoft Exchange.
Os dados do banco de dados são movidos do serviço de replicação do Microsoft Exchange do servidor de origem para o serviço de replicação do Microsoft Exchange do servidor de destino.
O serviço de Replicação do Microsoft Exchange no servidor de destino grava a cópia do banco de dados em um diretório temporário localizado no diretório principal do banco de dados chamado temp-seeding.
A operação de backup de streaming no servidor de origem termina quando se atinge o final do banco de dados.
A operação de gravação no servidor de destino é concluída e o banco de dados é movido do diretório temp-seeding para o local final. O diretório temp-seeding é excluído.
No servidor de destino, o serviço de replicação do Microsoft Exchange usa um proxy para uma solicitação ao serviço de pesquisa do Microsoft Exchange para montar o catálogo do índice de conteúdo, caso ele exista. Se houver arquivos de catálogo desatualizados existentes de uma instância anterior da cópia do banco de dados, haverá falha na operação da montagem, que dispara a necessidade de replicar o catálogo do servidor de origem. Da mesma forma, se o catálogo não existir em uma nova instância da cópia do banco de dados no servidor de destino, uma cópia do catálogo será obrigatória. O serviço de replicação do Microsoft Exchange orienta o serviço de pesquisa do Microsoft Exchange a suspender a indexação da cópia do banco de dados enquanto um novo catálogo é copiado da origem.
O serviço de replicação do Microsoft Exchange no servidor de destino envia uma solicitação de catálogo de propagação para o serviço de replicação do Microsoft Exchange no servidor de origem.
No servidor de origem, o serviço de replicação do Microsoft Exchange solicita as informações sobre o diretório do serviço de pesquisa do Microsoft Exchange e a suspensão dessa indexação.
O serviço de pesquisa do Microsoft Exchange no servidor de origem retorna as informações sobre o diretório do catálogo de pesquisa para o serviço de replicação do Microsoft Exchange.
O serviço de replicação do Microsoft Exchange no servidor de origem lê os arquivos de catálogo a partir do diretório.
O serviço de replicação do Microsoft Exchange no servidor de origem move os dados do catálogo para o serviço de replicação do Microsoft Exchange no servidor de destino, usando uma conexão na rede de replicação. Após a conclusão da leitura, o serviço de replicação do Microsoft Exchange envia uma solicitação para o serviço de pesquisa do Microsoft Exchange, para retomar a indexação do banco de dados de origem.
Se houver algum arquivo de catálogo existente no servidor de destino no diretório, o serviço de replicação do Microsoft Exchange no servidor de destino o excluirá.
O serviço de Replicação do Microsoft Exchange no servidor de destino grava os dados do catálogo em um diretório temporário chamado CiSeed.Temp até que os dados sejam completamente transferidos.
O serviço de replicação do Microsoft Exchange move todos os dados do catálogo para o local final.
O serviço de replicação do Microsoft Exchange no servidor de destino retoma a indexação de pesquisa no banco de dados de destino.
O serviço de replicação do Microsoft Exchange no servidor de destino retorna um status de conclusão.
O resultado final da operação é passado para a interface administrativa a partir da qual o cmdlet foi chamado.
Configurar cópias de banco de dados
Após a criação de uma cópia de banco de dados, é possível exibir e modificar as definições de configuração quando necessário. É possível exibir algumas informações de configuração examinando a página Propriedades de uma cópia de banco de dados no EAC. Você também pode usar os cmdlets Get-MailboxDatabase e Set-MailboxDatabaseCopy no Shell de Gerenciamento do Exchange para exibir e configurar configurações de cópia de banco de dados, como tempo de atraso de reprodução, tempo de atraso de truncamento e ordem de preferência de ativação. Para instruções detalhadas sobre como visualizar e configurar as definições de cópia do banco de dados, consulte Configurar propriedades de cópia de banco de dados de caixa de correio.
Usar opções de retardo de truncamento e de retardo de repetição
As cópias de banco de dados de caixa de correio dão suporte ao uso de um tempo de retardo de repetição e de um tempo de retardo de truncamento, ambos configurados em minutos. A configuração de um tempo de retardo de repetição permite restaurar uma cópia de backup de banco de dados para uma hora específica. A configuração de um tempo de retardo de truncamento permite usar os logs em uma cópia de banco de dados passiva para se recuperar da perda de arquivos de log na cópia de banco de dados ativa. Como esses recursos resultam na criação temporária de arquivos de log, o uso de um deles afetará o projeto de armazenamento.
Tempo de retardo de repetição
O tempo de atraso de reprodução é uma propriedade de cópia de banco de dados de caixa de correio que especifica a quantidade de tempo, em minutos, para atrasar a reprodução de log para a cópia do banco de dados. O cronômetro do tempo de retardo de repetição se inicia quando um arquivo de log é replicado para a cópia passiva e passa com êxito pela inspeção. Atrasando a repetição dos logs para a cópia de banco de dados, você tem a possibilidade de recuperar o banco de dados para um ponto específico anterior. Uma cópia de banco de dados de caixa de correio configurada com um tempo de retardo de repetição maior que 0 é conhecida como uma cópia de banco de dados de caixa de correio com retardamento ou simplesmente uma cópia com retardamento.
Uma estratégia que usa cópias de banco de dados e recursos de contencioso em Exchange Server pode fornecer proteção contra uma série de falhas que normalmente causariam perda de dados. No entanto, esses recursos não podem fornecer proteção contra a perda de dados em caso de dano lógico, que, embora raro, pode causar a perda de dados. As cópias com retardamento foram criadas para evitar a perda de dados em caso de dano lógico. Em geral, há dois tipos de dano lógico:
Corrupção lógica do banco de dados: a soma de verificação de páginas de banco de dados corresponde, mas os dados nas páginas estão errados logicamente. Isso pode ocorrer quando o ESE tenta gravar em uma página de banco de dados e, mesmo que o sistema operacional retorne uma mensagem de êxito, os dados jamais são gravados no disco ou são gravados no lugar errado. Isso é conhecido como liberação perdida. Para evitar que liberações perdidas percam dados, o ESE inclui um mecanismo de detecção de liberação perdida no banco de dados com um recurso de aplicação de patch de página (restauração de página única).
Armazenar corrupção lógica: os dados são adicionados, excluídos ou manipulados de uma maneira que o usuário não espera. Esses casos normalmente são causados por aplicativos de terceiros. Ele normalmente é apenas um dano no sentido em que o usuário o considera assim. O repositório do Exchange considera a transação que produziu o dano lógico uma série de operações MAPI válidas. O recurso de contencioso em Exchange Server fornece proteção contra corrupção lógica do armazenamento (porque impede que o conteúdo seja excluído permanentemente por um usuário ou aplicativo). Entretanto, pode haver cenários em que uma caixa de correio de usuário se torne tão corrompida que seria mais fácil restaurar o banco de dados até um ponto no tempo antes da corrupção e depois exportar a caixa de correio do usuário, para recuperar dados não corrompidos.
A combinação das cópias de banco de dados, da diretiva de guarda e da restauração de página única do ESE deixa apenas o caso de dano lógico raro, mas catastrófico, do repositório. A decisão de usar uma cópia de banco de dados com um tempo de retardo de repetição (uma cópia com retardamento) dependerá dos aplicativos de terceiros usados e do histórico da organização com dano lógico ao repositório.
Se você optar por usar cópias com retardamento, lembre-se das seguintes implicações quanto ao uso:
O tempo de retardo de repetição é um valor configurado por administrador e, por padrão, permanece desabilitado.
A configuração do tempo de retardo de repetição tem uma definição padrão de zero dia e uma definição máxima de 14 dias.
As cópias com retardamento não são consideradas cópias altamente disponíveis. Em vez disso, elas foram criadas para fins de recuperação de desastre, para proteger do dano lógico ao armazenamento.
Quanto maior for o tempo de retardo de repetição definido, mais longo será o processo de recuperação do banco de dados. Dependendo do número de arquivos de log que precisam ser repetidos durante a recuperação e da velocidade na qual o hardware pode repeti-los, talvez sejam necessárias várias horas para recuperar um banco de dados.
Recomendamos que você determine se as cópias com retardamento são críticas para a estratégia de recuperação de desastre geral. Se o uso deles for crítico à estratégia, recomendamos o uso de várias cópias com retardamento ou o uso de uma RAID (Redundant Array of Independent Disks) para proteger uma única cópia com retardamento, se você não tiver várias cópias com retardamento. Se perder um disco ou ocorrer um dano, você não perderá o ponto com retardamento.
Cópias defasadas não podem ser corrigidas com o recurso de restauração de página única do ESE. Se uma cópia defasada encontrar corrupção de página de banco de dados (por exemplo, um erro de -1018), a cópia precisará ser resseada. O resseeding perderá o aspecto defasado da cópia.
Se você quiser que o banco de dados reproduza todos os arquivos de log e faça a cópia do banco de dados atual, ativar e recuperar uma cópia de banco de dados de caixa de correio defasada é um processo fácil . Se você quiser reproduzir arquivos de log até um ponto específico no tempo, a prosa é mais difícil porque você precisa manipular manualmente arquivos de log e executar Exchange Server Utilitários de Banco de Dados (Eseutil.exe).
Para obter etapas detalhadas sobre como ativar uma cópia de banco de dados de caixa de correio defasada, consulte Ativar uma cópia de banco de dados de caixa de correio defasada.
Tempo de retardo de truncamento
O tempo de atraso de truncamento é a propriedade de uma cópia de banco de dados de caixa de correio que especifica a quantidade de tempo, em minutos, para atrasar a exclusão de log para a cópia do banco de dados depois que o arquivo de log tiver sido reproduzido na cópia do banco de dados. O cronômetro do retardo de truncamento se inicia quando um arquivo de log é replicado para a cópia passiva e passa com êxito pela inspeção, além de ser repetido com êxito na cópia do banco de dados. Atrasando o truncamento dos logs da cópia de banco de dados, você tem a possibilidade de se recuperar de falhas que afetam os arquivos de log para a cópia ativa do banco de dados.
Cópias de banco de dados e truncamento de log
O truncamento de log funciona da mesma forma no Exchange 2016 e no Exchange 2019 como no Exchange 2010. O comportamento do truncamento é determinado pelas configurações do tempo de retardo de repetição e do tempo de retardo de truncamento da cópia.
Os seguintes critérios deverão ser atendidos para que um arquivo de log do banco de dados seja truncado quando as configurações do retardo forem deixadas em valores-padrão iguais a zero (desabilitadas):
O backup do arquivo de log deve ser feito com êxito, ou o registro em log circular deve ser habilitado.
O arquivo de log deve estar abaixo do ponto de verificação (o arquivo de log mínimo obrigatório à recuperação) para o banco de dados.
Todas as outras cópias com retardamento devem ter inspecionado o arquivo de log.
Todas as outras cópias (exceto cópias defasadas) devem ter reproduzido o arquivo de log.
Os seguintes critérios devem ser atendidos para que ocorra o truncamento de uma cópia de banco de dados com retardamento:
O arquivo de log deve estar abaixo do ponto de verificação do banco de dados.
O arquivo de log deve ser anterior a ReplayLagTime + TruncationLagTime.
O arquivo de log deve ter sido truncado na cópia ativa.
Em Exchange Server, a truncamento de log não ocorre em uma cópia de banco de dados de caixa de correio ativa quando uma ou mais cópias passivas são suspensas. Se você tiver planejado atividades de manutenção que vão demorar muito (por exemplo, alguns dias), você pode ter um acúmulo considerável de arquivos de log. Para evitar que a unidade de log fiquei cheia de logs de transação, você pode remover a cópia do banco de dados passiva afetada, ao invés de suspendê-la. Quando a manutenção planejada estiver concluída, você pode readicionar a cópia do banco de dados passiva.
Exchange Server agora tem um recurso chamado truncamento solto que é desabilitado por padrão. Durante operações normais, cada cópia do banco de dados mantém logs que precisam ser enviados às outras cópias do banco de dados até que todas as cópias de um banco de dados confirmem ter reproduzido (cópias passivas) ou recebido (cópias atrasadas) os arquivos de log. Este é o comportamento padrão de truncamento de log. Se uma cópia do banco de dados ficar offline por algum motivo, os arquivos de log começam a se acumular nos discos usados pelas outras cópias do banco de dados. Se a cópia do banco de dados afetada continuar offline por um longo período, isto fará com que as demais cópias do banco de dados fiquem sem espaço em disco.
O comportamento de truncamento é diferente quando o truncamento solto e o registro em log circular são habilitados. Cada cópia de banco de dados rastreia seu próprio espaço livre em disco e aplica o comportamento de truncamento flexível caso o espaço livre seja reduzido.
Para a cópia ativa, a cópia isolada mais antiga (a cópia de banco de dados passiva que está mais longe da reprodução do log) é ignorada e o truncamento respeita as cópias passivas mais antigas restantes. A cópia do banco de dados ativa é onde o truncamento global é calculado.
Para uma cópia passiva, se o espaço ficar baixo, ele truncará independentemente seus arquivos de log usando os parâmetros configurados descritos posteriormente na tabela Valor do Registro. As cópias passivas tentarão respeitar a decisão de truncamento tomada na cópia ativa. Apesar da implicação do nome MinCopiesToProtect, o Exchange só ignorará a cópia isolada mais antiga conhecida no momento da execução do truncamento.
Quando o banco de dados offline ficar novamente online, estarão faltando arquivos de log que foram excluídos das outras cópias íntegras, e o status da cópia do banco de dados será FailedAndSuspended. Nesse caso, se o Autoreseed estiver configurado, a cópia afetada será automaticamente repropagada. Se o recurso Autoreseed não estiver configurado, a cópia do banco de dados precisará ser propagada manualmente por um administrador.
Se o registro em log circular estiver desabilitado, a truncação solta respeitará os backups se eles tiverem sido feitos, portanto, se os logs não tiverem sido apoiados, eles não serão removidos por truncamento frouxo.
Truncamento é um recurso recomendado para a arquitetura preferencial em que os backups não são usados e o log circular está habilitado.
A quantidade necessária de cópias íntegras, o limite de espaço livre em disco e a quantidade de logs que deve ser mantida são parâmetros que podem ser configurados. Por padrão, o limite de espaço livre em disco é de 204800 MB (200 GB) e a quantidade de logs a manter é de 100.000 (100 GB) para cópias passivas e de 10.000 (10 GB) para cópias ativas.
A habilitação do truncamento flexível e a configuração dos parâmetros de truncamento flexível são obtidas pela edição do Registro do Windows em cada membro do DAG. Há três valores do registro que podem ser configurados que são armazenados em HKLM\Software\Microsoft\ExchangeServer\v15\BackupInformation. Os seguintes valores DWORD da chave BackupInformation não existem por padrão e devem ser criados manualmente. Os valores do Registro DWORD em BackupInformation são descritos na tabela abaixo:
| Valor de Registro | Descrição | Valor padrão |
|---|---|---|
| LooseTruncation_MinCopiesToProtect | Esta chave é usada para habilitar o truncamento flexível. Ela representa a quantidade de cópias passivas a proteger do truncamento flexível na cópia ativa de um banco de dados. A definição do valor desta chave como 0 desativa o truncamento flexível. | 0 |
| LooseTruncation_MinDiskFreeSpaceThresholdInMB | Limite disponível de espaço em disco (em MB) para o acionamento de truncamento flexível. Se o espaço livre em disco ficar abaixo desse valor, o truncamento flexível será acionado. | Se este valor do registro não estiver configurado, o valor padrão usado pelo truncamento flexível será 200 GB. |
| LooseTruncation_MinLogsToProtect | A quantidade mínima de arquivos de log a ser mantida em cópias íntegras cujos logs estejam sendo truncados. Se esse valor do registro estiver configurado, então o valor configurado se aplicará às cópias ativas e passivas. | Se esse valor do registro não estiver configurado, então os valores padrão de 100.000 para cópias de banco de dados passivas e de 10.000 para cópias de banco de dados ativas serão usados. |
Ao usar o LooseTruncation_MinLogsToProtect valor do registro, observe que o comportamento é diferente para cópias de banco de dados ativo e passivo. Na cópia do banco de dados ativo, esse é o número de logs extras que são mantidos anteriores aos exigidos pelas cópias passivas protegidas e pelo intervalo necessário da cópia ativa. Em uma cópia de banco de dados passivo, esse é o número de logs mantidos no log disponível mais recente. Um décimo desse número também é usado para manter logs antes do intervalo necessário dessa cópia passiva. Os dois limites estão em vigor para garantir que as cópias de banco de dados defasadas não ocuparem muito espaço, já que o intervalo necessário normalmente é muito grande.
Política de ativação do banco de dados
Há cenários nos quais você talvez queira criar uma cópia de banco de dados de caixa de correio e impedir o sistema de ativar automaticamente essa cópia em caso de falha, por exemplo:
Se você implantar uma ou mais cópias de banco de dados de caixa de correio em um datacenter alternativo ou em espera.
Se você configurar uma cópia de banco de dados com retardo para fins de recuperação.
Se você estiver executando a manutenção ou uma atualização de um servidor.
Em cada um dos cenários anteriores, você tem cópias de banco de dados que não deseja que o sistema ative automaticamente. Para impedir que o sistema ative automaticamente uma cópia de banco de dados de caixa de correio, é possível configurar a cópia a ser bloqueada (suspensa) para ativação. Isso permite ao sistema manter a atualidade do banco de dados ao longo de todo o envio de logs e repetição, mas impede o sistema de ativar automaticamente e usar a cópia. As cópias bloqueadas para ativação devem ser ativadas manualmente por um administrador. Você pode configurar a política de ativação de banco de dados para um servidor inteiro usando o cmdlet Set-MailboxServer ou uma cópia de banco de dados individual usando o cmdlet Set-MailboxDatabaseCopy para definir o parâmetro DatabaseCopyAutoActivationPolicy como Bloqueado.
Para mais informações sobre como configurar a diretiva de ativação do banco de dados, consulte Configurar a política de ativação para uma cópia do banco de dados de caixa de correio.
Efeito das movimentações de caixa de correio sobre a replicação contínua
Em um banco de dados de caixa de correio com uma taxa alta de geração de log, há uma chance maior de perda de dados se a replicação das cópias de banco de dados passivas não conseguir acompanhar a geração do log. Um cenário que pode incluir uma alta taxa de geração de log é a movimentação de caixa de correio. Exchange Server inclui uma API de Garantia de Dados usada por serviços como o MRS (Serviço de Replicação de Caixa de Correio do Exchange) para verificar a integridade da arquitetura de cópia de banco de dados com base no valor do parâmetro DataMoveReplicationConstraint definido pelo sistema ou por um administrador. Especificamente, a API de Garantia de Dados pode ser usada para:
Verifique a integridade da replicação: confirma se o número de pré-requisitos de cópias de banco de dados está disponível.
Verificar o flush de replicação: confirma que os arquivos de log necessários foram reproduzidos no número de pré-requisitos de cópias de banco de dados.
Quando executada, a API retorna as seguintes informações de status para o aplicativo fazendo a chamada:
Repetição: significa que há erros transitórios que impedem que uma condição seja verificada no banco de dados.
Satisfeito: significa que o banco de dados atende às condições necessárias ou o banco de dados não é replicado.
NotSatisfied: significa que o banco de dados não atende às condições necessárias. Além disso, as informações são fornecidas ao aplicativo fazendo a chamada em relação a por que a resposta NotSatisfied foi retornada.
O valor do parâmetro DataMoveReplicationConstraint para o banco de dados da caixa de correio determina quantas cópias de banco de dados devem ser avaliadas como parte da solicitação. O parâmetro DataMoveReplicationConstraint tem os seguintes valores possíveis:
None: quando você cria um banco de dados de caixa de correio, esse valor é definido por padrão. Quando esse valor é definido, as condições da API de Garantia de Dados são ignoradas. Essa configuração deve ser usada apenas para bancos de dados de caixa de correio que não são replicados.SecondCopy: esse é o valor padrão quando você adiciona a segunda cópia de um banco de dados de caixa de correio. Quando esse valor é definido, pelo menos uma cópia de banco de dados passiva deve atender às condições de API de Garantia de Dados.SecondDatacenter: quando esse valor é definido, pelo menos uma cópia de banco de dados passivo em outro site do Active Directory deve atender às condições da API de Garantia de Dados.AllDatacenters: quando esse valor é definido, pelo menos uma cópia de banco de dados passivo em cada site do Active Directory deve atender às condições da API de Garantia de Dados.AllCopies: quando esse valor é definido, todas as cópias do banco de dados da caixa de correio devem atender às condições da API de Garantia de Dados.
Verificar a Integridade da Replicação
Quando a API de Garantia de Dados é executada para avaliar a integridade da infraestrutura da cópia de banco de dados, vários itens são avaliados.
Em todos os cenários, a cópia passiva do banco de dados deve atender às seguintes condições:
Estar íntegra.
Ter uma fila de repetição dentro de 10 minutos do tempo de retardo de repetição.
Ter um comprimento de fila de cópia de menos de 10 logs.
Ter um comprimento média de fila de cópia de menos de 10 logs. O comprimento médio da fila de cópia é computado com base no número de vezes que o aplicativo consultou o status do banco de dados.
| Se o parâmetro DataMoveReplicationConstraint estiver definido como... | Então, para um determinado banco de dados... |
|---|---|
SecondCopy |
Pelo menos uma cópia de banco de dados passivo para um banco de dados replicado deve atender às condições descritas anteriormente. |
SecondDatacenter |
Pelo menos uma cópia de banco de dados passivo em outro site do Active Directory deve atender às condições descritas anteriormente. |
AllDatacenters |
A cópia ativa deve ser montada e uma cópia passiva em cada site do Active Directory deve atender às condições descritas anteriormente. |
AllCopies |
A cópia ativa deve ser montada e todas as cópias de banco de dados passivos devem atender às condições descritas anteriormente. |
Verificar Despejo de Replicação
A API de Garantia de Dados também pode ser usada para validar que um número de pré-requisito de cópias de banco de dados tenham repetido os logs de transação requeridos. Isso é verificado comparando-se o carimbo de data/hora da última repetição de log com o carimbo de confirmação do serviço chamador (na maioria dos casos, esse é o carimbo de data/hora do último arquivo de log que contém os dados necessários) adicionado de cinco segundos, para lidar com desvios, atrasos ou adiantamentos do relógio do sistema). Se o carimbo de data/hora de reprodução for maior que o carimbo de data/hora de confirmação, o parâmetro DataMoveReplicationConstraint será satisfeito. Se o carimbo de data/hora de reprodução for menor que o carimbo de data/hora de confirmação, o DataMoveReplicationConstraint não será satisfeito.
Antes de mover um grande número de caixas de correio para ou de bancos de dados de replicação em um DAG, recomendamos configurar o parâmetro DataMoveReplicationConstraint em cada banco de dados de caixa de correio de acordo com o seguinte:
| Se você estiver implantando... | Defina DataMoveReplicationConstraint como... |
|---|---|
| Bancos de dados de caixa de correio que não tem nenhuma cópia de banco de dados | None |
| Um DAG dentro de um único site do Active Directory | SecondCopy |
| Um DAG em vários datacenters usando um site do Active Directory alongado | SecondCopy |
| Um DAG que abrange dois sites do Activee Directory e você terá cópias de banco de dados altamente disponíveis em cada site | SecondDatacenter |
| Um DAG que abrange dois sites do Active Directory e você terá somente cópias do banco de dados com retardo no segundo site | SecondCopy Isso é porque a API de Garantia de Dados não irá garantir os dados sendo comprometidos até que o arquivo de log seja reproduzido dentro da cópia do bando de dados e, devido à natureza da cópia do banco de dados sofrendo o retardo, essa restrição fará a solicitação de movimentação falhar, a menos que o valor de ReplayLagTime da cópia do banco de dados com retardo seja menor que 30 minutos. |
| Um DAG que abranja três ou mais sites do Active Directory, e cada site irá conter cópias do banco de dados de alta disponibilidade | AllDatacenters |
Balancear cópias de banco de dados
Devido à natureza inerente dos DAGs, como resultado das alternâncias e dos failovers de banco de dados, as cópias de banco de dados de caixa de correio ativas alterarão hosts várias vezes durante toda a existência de um DAG. Como resultado, os DAGs podem se tornar desbalanceados em termos de distribuição de cópia de banco de dados de caixa de correio ativa. A tabela a seguir mostra um exemplo de DAG que tem quatro bancos de dados com quatro cópias de cada banco de dados (para um total de 16 bancos de dados em cada servidor) com uma distribuição irregular de cópias de banco de dados ativas.
DAG com distribuição de cópia ativa desbalanceada
| Servidor | Número de bancos de dados ativos | Número de bancos de dados passivos | Número de bancos de dados montados | Número de bancos de dados desmontados | Lista de contagem de preferência |
|---|---|---|---|---|---|
| EX1 | 5 | 11 | 5 | 0 | 4, 4, 3, 5 |
| EX2 | 1 | 15 | 1 | 0 | 1, 8, 6, 1 |
| Ex3 | 12 | 4 | 12 | 0 | 13, 2, 1, 0 |
| EX4 | 1 | 15 | 1 | 0 | 1, 1, 5, 9 |
No exemplo anterior, há quatro cópias de cada banco de dados e, por isso, somente quatro valores possíveis para preferência de ativação (1, 2, 3 ou 4). A coluna Lista de contagem de preferência mostra a contagem do número de bancos de dados com cada um desses valores. Por exemplo, em EX3, há 13 cópias de bancos de dados com uma preferência de ativação de 1, duas cópias com uma preferência de ativação de 2, uma cópia com uma preferência de ativação de 3 e nenhuma cópia com uma preferência de ativação de 4.
Como é possível ver, esse DAG não é balanceado em termos do número de bancos de dados ativos hospedados por todos os membros do DAG, o número de bancos de dados passivos hospedados pelos membros do DAG ou a contagem de preferência de ativação dos bancos de dados hospedados.
Você pode usar o script RedistributeActiveDatabases.ps1 para equilibrar as cópias de banco de dados de caixas de correio ativas em um DAG. Esse script move bancos de dados entre suas cópias em uma tentativa de equilibrar o número de bancos de dados montados em cada servidor do DAG. Se necessário, o script também tentará equilibrar os bancos de dados ativos entre sites.
O script fornece duas opções para balancear cópias de banco de dados ativas em um DAG:
BalanceDbsByActivationPreference: quando essa opção é especificada, o script tenta mover bancos de dados para sua cópia mais preferencial (com base na preferência de ativação) sem considerar o site do Active Directory.
BalanceDbsBySiteAndActivationPreference: quando essa opção é especificada, o script tenta mover bancos de dados ativos para sua cópia mais preferencial, ao mesmo tempo em que tenta equilibrar bancos de dados ativos em cada site do Active Directory.
Após executar o script com a primeira opção, o DAG anterior desbalanceado se tornará balanceado, como mostrado na seguinte tabela.
DAG com distribuição de cópia ativa balanceada
| Servidor | Número de bancos de dados ativos | Número de bancos de dados passivos | Número de bancos de dados montados | Número de bancos de dados desmontados | Lista de contagem de preferência |
|---|---|---|---|---|---|
| EX1 | 4 | 12 | 4 | 0 | 4, 4, 4, 4 |
| EX2 | 4 | 12 | 4 | 0 | 4, 4, 4, 4 |
| Ex3 | 4 | 12 | 4 | 0 | 4, 4, 4, 4 |
| EX4 | 4 | 12 | 4 | 0 | 4, 4, 4, 4 |
Como mostrado na tabela anterior, esse DAG está agora balanceado em termos do número de bancos de dados ativos e passivos em cada servidor e preferência de ativação nos servidores.
A tabela a seguir lista os parâmetros disponíveis para o script RedistributeActiveDatabases.ps1.
Parâmetros do script RedistributeActiveDatabases.ps1
| Parâmetro | Descrição |
|---|---|
| DagName | Especifica o nome do DAG que você deseja rebalancear. Se esse parâmetro for omitido, o DAG do qual o servidor local é um membro será usado. |
| BalanceDbsByActivationPreference | Especifica que o script deve mover bancos de dados para a cópia mais preferencial sem considerar o site do Active Directory. |
| BalanceDbsBySiteAndActivationPreference | Especifica que o script deve tentar mover bancos de dados ativos para sua cópia mais preferencial, ao mesmo tempo em que tenta equilibrar bancos de dados ativos em cada site do Active Directory. |
| ShowFinalDatabaseDistribution | Especifica que um relatório da distribuição de banco de dados atual deve ser exibido após a conclusão da redistribuição. |
| AllowedDeviationFromMeanPercentage | Especifica a variação permitida de bancos de dados ativos entre sites, expressa em porcentagem. O padrão é 20%. Por exemplo, se houver 99 bancos de dados distribuídos por 3 sites, a distribuição ideal será 33 bancos de dados em cada site. Se o desvio permitido for de 20%, o script tentará equilibrar a distribuição dos bancos de dados de forma que cada site não possua mais do que 10% a mais ou a menos desse número. 10% de 33 são 3,3, que são arredondados para 4. Portanto, o script tentará ter entre 29 e 37 bancos de dados em cada site. |
| ShowDatabaseCurrentActives | Especifica se o script produz um relatório para cada banco de dados, detalhando como o banco de dados foi movido e se ele está agora ativo em sua cópia mais preferida. |
| ShowDatabaseDistributionByServer | Especifica que o script produz um relatório para cada servidor mostrando sua distribuição de banco de dados. |
| RunOnlyOnPAM | Especifica que o script seja executado somente no membro do DAG que atualmente tem a função PAM. O script verifica se está sendo executado a partir do PAM. Se não estiver sendo executado a partir do PAM, o script será finalizado. |
| LogEvents | Especifica se o script gera logs de um evento (MsExchangeRepl evento 4115) contendo um resumo das ações. |
| IncludeNonReplicatedDatabases | Especifica que o script deve incluir bancos de dados não replicados (bancos de dados sem cópias) ao determinar como redistribuir os bancos de dados ativos. Embora bancos de dados não replicados não possam ser movidos, eles podem afetar a distribuição dos bancos de dados replicados. |
| Confirmar | A opção Confirm pode ser usada para suprimir o prompt de confirmação que aparece por padrão quando esse script é executado. Para suprimir o prompt de confirmação, use a sintaxe -Confirm:$False. Você deve incluir dois-pontos ( : ) na sintaxe. |
Exemplos de RedistributeActiveDatabases.ps1
Esse exemplo mostra a distribuição de banco de dados para um DAG, incluindo a lista de contagem de preferência.
RedistributeActiveDatabases.ps1 -DagName DAG1 -ShowDatabaseDistributionByServer | Format-Table
Esse exemplo redistribui e balanceia as cópias de banco de dados de caixa de correio ativas em um DAG usando a preferência de ativação sem solicitar uma entrada.
RedistributeActiveDatabases.ps1 -DagName DAG1 -BalanceDbsByActivationPreference -Confirm:$False
Esse exemplo redistribui e balanceia as cópias de banco de dados de caixa de correio ativas em um DAG usando a preferência de ativação e produz um resumo da distribuição.
RedistributeActiveDatabases.ps1 -DagName DAG1 -BalanceDbsByActivationPreference -ShowFinalDatabaseDistribution
Monitorar cópias de banco de dados
Você pode exibir várias informações, incluindo o comprimento de filas de cópia, comprimento da fila de repetição, informações de estado de status e índice de conteúdo, examinando os detalhes de uma cópia de banco de dados no EAC. Você também pode usar o cmdlet Get-MailboxDatabaseCopyStatus no Shell de Gerenciamento do Exchange para exibir uma variedade de informações de status para uma cópia de banco de dados.
Observação
Uma cópia de banco de dados será a primeira defesa se ocorrer uma falha que afete a cópia ativa de um banco de dados. Portanto, é fundamental monitorar a integridade e o status das cópias de banco de dados para garantir que elas estejam disponíveis quando necessário.
Para obter mais informações sobre o monitoramento de cópias de banco de dados, consulte Monitorar grupos de disponibilidade de banco de dados.
Remover uma cópia de banco de dados
Uma cópia de banco de dados pode ser removida a qualquer momento usando o EAC ou usando o cmdlet Remove-MailboxDatabaseCopy no Shell de Gerenciamento do Exchange. Após remover uma cópia de banco de dados, você precisará excluir manualmente todos os arquivos de log de transações e de banco de dados do servidor do qual a cópia de banco de dados está sendo removida. Para obter etapas detalhadas sobre como remover uma cópia de um banco de dados, consulte Remover uma cópia do banco de dados de caixa de correio.
Alternâncias de banco de dados
O servidor de Caixa de Correio que hospeda a cópia ativa de um banco de dados é conhecido como o banco de dados de caixa de correio mestre. O processo de ativação de uma cópia de banco de dados passiva altera o banco de dados de caixa de correio mestre do banco de dados e transforma a cópia passiva na nova cópia ativa. Esse processo é chamado de alternância de banco de dados. Em uma alternância de banco de dados, a cópia ativa de um banco de dados é desmontada em um servidor de Caixa de Correio e uma cópia passiva desse banco de dados é montada como o novo banco de dados de caixa de correio ativo em outro servidor de Caixa de Correio. Ao realizar uma alternância, também é possível substituir a configuração da discagem automática de montagem do banco de dados no novo banco de dados de caixa de correio mestre.
É possível identificar rapidamente que servidor de Caixa de Correio é o banco de dados de caixa de correio mestre atual revisando-se a coluna da direita na guia Cópias de Banco de Dados no EAC. Você pode executar uma alternância usando o link Ativar no EAC ou usando o cmdlet Move-ActiveMailboxDatabase no Shell de Gerenciamento do Exchange.
Há várias verificações internas que serão executadas antes que uma cópia passiva seja ativada. Em alguns casos, a alternância de banco de dados é bloqueada ou cancelada. Em outros casos, você pode usar cmdlets para mover ou ignorar algumas verificações.
O status da cópia de banco de dados é verificado. Se a cópia de banco de dados estiver em um estado com falha, a alternância será bloqueada. Você pode substituir esse comportamento e ignorar a verificação de integridade usando o parâmetro SkipHealthChecks do cmdlet Move-ActiveMailboxDatabase . Esse parâmetro permite mover a cópia ativa para uma cópia de banco de dados em um estado com falha.
A cópia do banco de dados ativo é verificada para saber se ela é uma fonte de propagação para quaisquer cópias passivas do banco de dados. Se a cópia ativa estiver sendo usada como uma fonte para a propagação, a alternância é bloqueada. Você pode substituir esse comportamento e ignorar a verificação de origem de semente usando o parâmetro SkipActiveCopyChecks do cmdlet Move-ActiveMailboxDatabase . Esse parâmetro permite que você mova uma cópia ativa que está sendo usada como uma fonte de propagação. Usar esse parâmetro irá fazer com que a operação de propagação seja cancelada e considerada falha.
Os comprimentos da fila de cópia e da fila de repetição para a cópia de banco de dados são verificados para assegurar-se de que os valores estejam dentro dos critérios configurados. Além disso, a cópia de banco de dados é verificada para assegurar-se de que ela não esteja em uso como uma origem para propagação. Se os valores dos comprimentos das filas estiverem fora dos critérios configurados ou se o banco de dados estiver sendo usado como uma origem para propagação, a alternância será bloqueada. Você pode substituir esse comportamento e ignorar essas verificações usando o parâmetro SkipLagChecks do cmdlet Move-ActiveMailboxDatabase . Esse parâmetro permite a ativação de uma cópia com filas de repetição e cópia fora dos critérios configurados.
O estado do catálogo de pesquisa (índice do conteúdo) da cópia de banco de dados é verificado. Se o catálogo de pesquisa não estiver atualizado, estiver em um estado não íntegro ou estiver corrompido, a alternância será bloqueada. Você pode substituir esse comportamento e ignorar a verificação do catálogo de pesquisa usando o parâmetro SkipClientExperienceChecks do cmdlet Move-ActiveMailboxDatabase . Esse parâmetro faz essa pesquisa ignorar a verificação da integridade do catálogo. Se o catálogo de pesquisa da cópia de banco de dados que você estiver ativando estiver em um estado não íntegro ou inutilizável e você usar esse parâmetro para ignorar a verificação da integridade do catálogo, você precisará rastrear ou propagar o catálogo de pesquisa novamente.
Ao executar uma alternância de banco de dados, você também tem a opção de substituir as configurações de discagem de montagem configuradas para o servidor que hospeda a cópia passiva do banco de dados que está sendo ativada. Usar o parâmetro MountDialOverride do cmdlet Move-ActiveMailboxDatabase instrui o servidor de destino a substituir suas próprias configurações de discagem de montagem e usá-las especificadas pelo parâmetro MountDialOverride .
Para instruções detalhadas sobre como realizar uma alternância de uma cópia de banco de dados, consulte Ativar uma cópia do banco de dados de caixa de correio.