Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
No Exchange Server, pode utilizar o Console de Gerenciamento do Exchange (EAC) ou a Shell de Gestão do Exchange para adicionar cópias da base de dados da caixa de correio depois de um grupo de disponibilidade de base de dados (DAG) ter sido criado, configurado e preenchido com membros do servidor da Caixa de Correio.
Após a criação de várias cópias de uma base de dados, pode utilizar o EAC ou a Shell de Gestão do Exchange para monitorizar o estado de funcionamento e status de cada cópia e para executar outras tarefas de gestão associadas a cópias de base 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.
Por vários motivos, como a realização da manutenção planeada, poderá ter de suspender e retomar a atividade de replicação contínua para uma cópia da base de dados. Além disso, algumas tarefas administrativas, como a propagação, exigem que suspenda primeiro uma cópia da base de dados. Recomendamos que suspenda toda a atividade de replicação quando o caminho da base de dados ou os respetivos ficheiros de registo estiverem a ser alterados. Pode suspender e retomar a atividade de cópia da base de dados com o EAC ou ao executar os cmdlets Suspend-MailboxDatabaseCopy e Resume-MailboxDatabaseCopy na Shell de Gestão 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.
A propagação, também conhecida como atualização, é o processo no qual uma base de dados em branco ou uma cópia da base de dados de produção é adicionada à localização de cópia de destino noutro servidor da Caixa de Correio no mesmo DAG que a base de dados ativa. Ele se torna o banco de dados de linha de base para a cópia mantida pelo servidor.
Consoante a situação, pode propagar uma base de dados através de um processo automático ou de um processo manual que inicia. 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 quiser propagar manualmente uma cópia da base de dados e não quiser que a propagação automática ocorra ao criar a cópia, pode utilizar o parâmetro SeedingPostponed ao executar o cmdlet Add-MailboxDatabaseCopy .
As cópias da base de dados raramente precisam de ser reseedidas após a propagação inicial. No entanto, se a reseeding for necessária ou se quiser propagar manualmente uma cópia da base de dados em vez de ter o sistema a propagar automaticamente, tem duas opções. Pode reutilizar uma base de dados com o assistente Atualizar Cópia da Base de Dados da Caixa de Correio no EAC ou através do cmdlet Update-MailboxDatabaseCopy na Shell de Gestão 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.
Quando efetua uma operação de seed, pode optar por propagar a cópia da base de dados da caixa de correio, o catálogo de índices de conteúdos para a cópia da base de dados da caixa de correio ou a cópia da base de dados e a cópia do catálogo de índices de conteúdos. 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 propagar apenas a cópia da base de dados da caixa de correio sem propagar o catálogo de índices de conteúdos, utilize 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.
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 utilizar uma cópia específica como origem para propagação ao adicionar uma nova cópia da base de dados, pode fazer o seguinte:
Utilize o parâmetro SeedingPostponed ao executar o cmdlet Add-MailboxDatabaseCopy para adicionar a cópia da base de dados. Se não utilizar o parâmetro SeedingPostponed , a cópia da base de dados será explicitamente propagada com a cópia ativa da base de dados como a origem.
Pode especificar o servidor de origem que pretende utilizar como parte do assistente Atualizar Cópia da Base de Dados da Caixa de Correio no EAC ou pode utilizar o parâmetro SourceServer ao executar o cmdlet Update-MailboxDatabaseCopy para especificar o servidor de origem pretendido para propagação. No exemplo anterior, você especificaria MBX3 como o servidor de origem. Se não utilizar o parâmetro SourceServer , a cópia da base de dados será explicitamente propagada da cópia ativa da base de dados.
Além de selecionar um servidor de origem específico para propagar uma cópia da base de dados da caixa de correio, também pode utilizar a Shell de Gestão do Exchange para especificar as redes DAG a utilizar. Tem a opção de substituir as definições de compressão e encriptação da rede DAG durante a operação de seed.
Pode especificar as redes que pretende utilizar para propagação utilizando o parâmetro Rede ao executar o cmdlet Update-MailboxDatabaseCopy e especificar as redes DAG que pretende utilizar. Se não utilizar o parâmetro Rede , o sistema utiliza o seguinte comportamento predefinido para selecionar uma rede a utilizar para a operação de propagação:
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 predefinições utilizam encriptação e compressã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.
Quando inicia um processo de propagação com os cmdlets Add-MailboxDatabaseCopy ou Update-MailboxDatabaseCopy , são executadas as seguintes tarefas:
As propriedades da base de dados do Active Directory são lidas para validar a base de dados e os servidores especificados e para verificar se os servidores de origem e de destino estão a executar Exchange Server, são ambos membros do mesmo DAG e que a base de dados especificada não é uma base 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 Replicação do Microsoft Exchange no servidor de destino escreve a cópia da base de dados num diretório temporário localizado no diretório da base de dados main denominado propagação temporária.
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 Replicação do Microsoft Exchange no servidor de destino escreve os dados do catálogo num 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.
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. Também pode utilizar os cmdlets Get-MailboxDatabase e Set-MailboxDatabaseCopy na Shell de Gestão do Exchange para ver e configurar as definições de cópia da base de dados, como o tempo de atraso de repetição, o tempo de atraso da truncagem e a 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.
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.
O tempo de atraso de repetição é uma propriedade de cópia da base de dados da caixa de correio que especifica a quantidade de tempo, em minutos, para atrasar a repetição do registo da cópia da base 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 utiliza cópias de base de dados e as funcionalidades de retenção de litígios no 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:
Danos lógicos na base de dados: a soma de verificação das páginas da base 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 danos lógicos: os dados são adicionados, eliminados ou manipulados de uma forma que o utilizador 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. A funcionalidade de retenção de litígios no Exchange Server fornece proteção contra danos lógicos no arquivo (porque impede que o conteúdo seja eliminado permanentemente por um utilizador ou aplicação). 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.
As cópias com atraso não podem ser corrigidas com a funcionalidade de restauro de página única do ESE. Se uma cópia com atraso encontrar danos na página da base de dados (por exemplo, um erro -1018), a cópia terá de ser reutilizada. A reseeding perderá o aspeto atrasado da cópia.
Se quiser que a base de dados reproduza todos os ficheiros de registo e torne a cópia da base de dados atual, ativar e recuperar uma cópia da base de dados da caixa de correio com atraso é um processo fácil. Se quiser reproduzir ficheiros de registo até um ponto específico no tempo, a prosess é mais difícil porque tem de manipular manualmente ficheiros de registo e executar Exchange Server Utilitários da Base de Dados (Eseutil.exe).
Para obter passos detalhados sobre como ativar uma cópia de base de dados de caixa de correio com atraso, consulte Ativar uma cópia da base de dados da caixa de correio com atraso.
O tempo de atraso da truncagem é a propriedade de uma cópia da base de dados da caixa de correio que especifica a quantidade de tempo, em minutos, para atrasar a eliminação do registo da cópia da base de dados depois de o ficheiro de registo ter sido reproduzido na cópia da base 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.
A truncagem de registos 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 com atraso) têm de ter reproduzido o ficheiro de registo.
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.
No Exchange Server, a truncagem de registos não ocorre numa cópia de base 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 uma funcionalidade chamada truncagem solta que está desativada por predefiniçã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 da truncagem é diferente quando a truncagem solta e o registo circular estão ativados. 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, truncará independentemente os respetivos ficheiros de registo com os parâmetros configurados descritos posteriormente na tabela Valor do Registo. 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 registo circular estiver desativado, a truncagem solta respeita as cópias de segurança se tiverem sido criadas, pelo que, se não tiver sido feita uma cópia de segurança dos registos, não serão removidos por Truncagem solta.
A truncagem é uma funcionalidade recomendada para a arquitetura preferencial em que as cópias de segurança não são utilizadas e o registo circular está ativado.
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 utilizar o valor do registo LooseTruncation_MinLogsToProtect, tenha em atenção que o comportamento é diferente para cópias de bases de dados ativas e passivas. Na cópia da base de dados ativa, este é o número de registos adicionais retidos antes dos necessários pelas cópias passivas protegidas e pelo intervalo necessário da cópia ativa. Numa cópia passiva da base de dados, este é o número de registos mantidos a partir do registo disponível mais recente. Um décimo deste número também é utilizado para manter os registos antes do intervalo necessário desta cópia passiva. Os dois limites estão implementados para garantir que as cópias da base de dados atrasadas não ocupam demasiado espaço, uma vez que o intervalo necessário é normalmente muito grande.
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 estiver a efetuar 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. Pode configurar a política de ativação da base de dados para um servidor inteiro com o cmdlet Set-MailboxServer ou uma cópia de base de dados individual com 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.
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 utilizada por serviços como o Serviço de Replicação da Caixa de Correio do Exchange (MRS) para marcar o estado de funcionamento da arquitetura de cópia da base de dados com base no valor do parâmetro DataMoveReplicationConstraint que foi definido pelo sistema ou por um administrador. Especificamente, a API de Garantia de Dados pode ser usada para:
Verificar o estado de funcionamento da replicação: confirma que o número de pré-requisitos das cópias da base de dados está disponível.
Verificar a eliminação da cache da replicação: confirma que os ficheiros de registo necessários foram reproduzidos em relação ao número de pré-requisitos de cópias da base de dados.
Quando executada, a API retorna as seguintes informações de status para o aplicativo fazendo a chamada:
Repetição: significa que existem erros transitórios que impedem que uma condição seja verificada na base de dados.
Satisfeito: significa que a base de dados cumpre as condições necessárias ou que a base de dados não é replicada.
NotSatisfied: significa que a base de dados não cumpre as 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 a base de dados da caixa de correio determina quantas cópias da base de dados devem ser avaliadas como parte do pedido. O parâmetro DataMoveReplicationConstraint tem os seguintes valores possíveis:
None: quando cria uma base de dados de caixa de correio, este valor é definido por predefiniçã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: este é o valor predefinido quando adiciona a segunda cópia de uma base 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 este valor é definido, pelo menos uma cópia passiva da base de dados noutro site do Active Directory tem de cumprir as condições da API de Garantia de Dados.AllDatacenters: quando este valor é definido, pelo menos uma cópia passiva da base de dados em cada site do Active Directory tem de cumprir as condições da API de Garantia de Dados.AllCopies: quando este valor é definido, todas as cópias da base de dados da caixa de correio têm de cumprir as 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 da base de dados tem de cumprir as 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... | Em seguida, para uma determinada base de dados... |
|---|---|
SecondCopy |
Pelo menos uma cópia passiva da base de dados para uma base de dados replicada tem de cumprir as condições descritas anteriormente. |
SecondDatacenter |
Pelo menos uma cópia passiva da base de dados noutro site do Active Directory tem de cumprir as condições descritas anteriormente. |
AllDatacenters |
A cópia ativa tem de ser montada e uma cópia passiva em cada site do Active Directory tem de cumprir as condições descritas anteriormente. |
AllCopies |
A cópia ativa tem de ser montada e todas as cópias passivas da base de dados têm de cumprir as 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 repetição for maior do que o carimbo de data/hora de consolidação, o parâmetro DataMoveReplicationConstraint é cumprido. Se o carimbo de data/hora de repetição for inferior ao carimbo de data/hora da consolidação, o DataMoveReplicationConstraint não será satisfeito.
Antes de mover um grande número de caixas de correio de/para bases de dados de replicação num DAG, recomendamos que configure o parâmetro DataMoveReplicationConstraint em cada base de dados de caixa de correio de acordo com o seguinte:
| Se estiver a implementar... | 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 Active Directory e terá cópias de base de dados de elevada disponibilidade 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 |
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 esta opção é especificada, o script tenta mover as bases de dados para a respetiva cópia preferida (com base na preferência de ativação) sem ter em conta o site do Active Directory.
BalanceDbsBySiteAndActivationPreference: quando esta opção é especificada, o script tenta mover bases de dados ativas para a respetiva cópia preferida, ao mesmo tempo que tenta equilibrar as bases de dados ativas 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 as bases de dados para a respetiva cópia preferida, independentemente do site do Active Directory. |
| BalanceDbsBySiteAndActivationPreference | Especifica que o script deve tentar mover bases de dados ativas para a respetiva cópia preferida, ao mesmo tempo que tenta equilibrar as bases de dados ativas 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. |
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
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. Também pode utilizar o cmdlet Get-MailboxDatabaseCopyStatus na Shell de Gestão do Exchange para ver uma variedade de informações de status para uma cópia da base 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. Por conseguinte, é fundamental monitorizar o estado de funcionamento e status das cópias da base de dados para garantir que estão disponíveis quando necessário.
Para obter mais informações sobre como monitorizar cópias de bases de dados, veja Monitorizar grupos de disponibilidade de bases de dados.
Uma cópia de base de dados pode ser removida em qualquer altura com o EAC ou com o cmdlet Remove-MailboxDatabaseCopy na Shell de Gestão 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.
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. Pode efetuar uma transição utilizando a ligação Ativar no EAC ou utilizando o cmdlet Move-ActiveMailboxDatabase na Shell de Gestão do Exchange.
Existem várias verificações internas que serão efetuadas antes de uma cópia passiva ser ativada. Em alguns casos, a ativação da base de dados é bloqueada ou cancelada. Noutros casos, pode utilizar 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. Pode substituir este comportamento e ignorar a marcar de estado de funcionamento com o parâmetro SkipHealthChecks do cmdlet Move-ActiveMailboxDatabase. Este parâmetro permite-lhe mover a cópia ativa para uma cópia de base de dados num estado de 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. Pode substituir este comportamento e ignorar o marcar de origem de propagação com 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. Pode substituir este comportamento e ignorar estas verificações com 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. Pode substituir este comportamento e ignorar o catálogo de pesquisa marcar com 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.
Quando efetua uma transição de base de dados, também tem a opção de substituir as definições de marcação de montagem configuradas para o servidor que aloja a cópia passiva da base de dados que está a ser ativada. A utilização do parâmetro MountDialOverride do cmdlet Move-ActiveMailboxDatabase instrui o servidor de destino a substituir as suas próprias definições de marcação de montagem e a utilizá-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.