Configurar o MySQL no Compute Engine

O Compute Engine oferece vários tipos de instâncias e opções de armazenamento para leitura e gravação de dados dos seus bancos de dados MySQL. Para garantir o melhor desempenho e custo para suas cargas de trabalho de banco de dados, recomendamos executar em produtos de infraestrutura como serviço (IaaS) de geração mais recente.

As recomendações de configuração a seguir consideram que as cargas de trabalho do MySQL são usadas com frequência em sistemas com muitas leituras, como processamento de transações on-line (OLTP) ou o banco de dados que oferece suporte a um aplicativo da Web típico. Elas também consideram opções de configuração comuns, como usar a versão 8.0 ou mais recente do MySQL e o mecanismo de armazenamento InnoDB. Para cargas de trabalho sensíveis à performance, talvez seja necessário ajustar as configurações. Recomendamos usar este guia como ponto de partida para a implantação e testar com sua carga de trabalho real para validar se a configuração atende às suas necessidades.

Escolher sua máquina virtual (VM)

Para cargas de trabalho do MySQL, recomendamos usar a geração mais recente das famílias de máquinas C e N, porque elas incluem formatos que funcionam bem para a maioria das configurações práticas do MySQL. Para uma introdução a essas séries de máquinas, consulte a seguinte Google Cloud postagem do blog. Essas famílias de máquinas usam o Titanium e são baseadas em gerações recentes de processadores Intel, AMD e Axion.

Foco na performance

Para cargas de trabalho sensíveis à performance, como bancos de dados MySQL essenciais aos negócios, recomendamos as instâncias C4 e C4A mais recentes, se estiverem disponíveis na sua região. Se você não conseguir acessar essas instâncias, as instâncias C3 e C3D oferecem um foco semelhante na performance.

Essas instâncias oferecem a latência mais baixa e consistente para operações vinculadas à computação e incluem os seguintes recursos úteis para cargas de trabalho focadas em desempenho:

  • Controle sobre eventos de manutenção do host com notificação antecipada
  • Controle do aumento de turbo de núcleo único para maior consistência de desempenho
  • Rede Tier_1 para maior largura de banda da rede

Se você estiver usando uma instância C4A, C3 ou C3D, também poderá usar unidades de estado sólido locais (SSDs locais) para atender a requisitos de desempenho específicos.

Otimizar para custo

Para cargas de trabalho em que a principal prioridade é otimizar o custo, como bancos de dados MySQL com níveis de tráfego baixos a médios ou bancos de dados usados em ambientes de teste ou desenvolvimento, recomendamos que você use as instâncias N4 mais recentes. Essas instâncias usam o gerenciamento dinâmico de recursos de próxima geração do Compute Engine para otimizar o custo total e manter um desempenho sólido, sem as garantias fortes oferecidas pelas instâncias C4, C4A, C3 e C3D. Para mais detalhes, consulte Gerenciamento de recursos dinâmicos de última geração.

Configurar o tamanho da VM

Para qualquer VM que você use, é importante escolher o tamanho certo para o nível de desempenho do MySQL que você quer alcançar.

Se você busca uma alta performance de transações de gravação por segundo (TPS), o principal fator a ser considerado é o armazenamento em blocos. Para mais detalhes, consulte Configurar o armazenamento em blocos, nesta página.

Se você busca um alto desempenho de consultas de leitura por segundo (QPS), recomendamos usar o pool de buffer baseado em RAM do MySQL para armazenar em cache dados ativos e reduzir os acessos ao disco. Para maximizar esses benefícios, siga estas etapas:

  • Escolha um tamanho de VM que garanta que o conjunto de trabalho, ou a quantidade total de dados que seu banco de dados processa de uma só vez, caiba no pool de buffers.
  • Dimensionar o pool de buffers para usar a maior parte da RAM na VM.

Para minimizar o custo de dimensionar sua VM dessa forma, recomendamos usar uma VM com uma alta proporção de RAM para CPUs virtuais (vCPUs) para evitar pagar por vCPUs que você não usa.

Para um equilíbrio ideal na maioria das cargas de trabalho do MySQL, determine o conjunto de trabalho da sua carga de trabalho e escolha o menor formato de instância highmem que se encaixe nesse conjunto de trabalho na RAM. As formas de instância highmem têm cerca de 8 GB de RAM por vCPU. Isso oferece memória suficiente para armazenar em cache um grande conjunto de trabalho, mantendo CPU suficiente para lidar com uma alta carga de consultas.

Para cargas de trabalho com grandes conjuntos de trabalho, mas baixas taxas de consultas, use instâncias N4 e otimize ainda mais o custo total com tipos de máquinas personalizadas e memória estendida para aumentar a proporção de RAM para vCPU.

Configurar a largura de banda da rede da VM

Na maioria dos casos de uso do MySQL, é possível manter os limites padrão de largura de banda da rede para sua instância. Se isso atender às suas necessidades, não será necessário fazer upgrade para a rede Tier_1.

Configurar o armazenamento em blocos

O Google Cloud Hyperdisk é a única geração de armazenamento em blocos durável disponível para famílias de VMs recentes do Compute Engine. Acreditamos que o Hyperdisk equilibrado é a melhor opção para a grande maioria das cargas de trabalho do MySQL. Para mais informações sobre o Hyperdisk, acesse a documentação do Hyperdisk.

Google Cloud Hyperdisk

O Hyperdisk Balanced oferece os seguintes recursos:

  • Latência de unidade de estado sólido (SSD) a baixo custo
  • Configurações de alto desempenho para aplicativos que precisam delas
  • Durabilidade melhor que 99,999% para proteger contra o risco de falha de hardware e corrupção silenciosa de dados em todo o setor
  • Criptografia de todos os dados do Hyperdisk em repouso com chaves de criptografia gerenciadas pelo Google ou pelo cliente

Selecione seu nível de performance

Com o Hyperdisk Balanced, você seleciona o nível de desempenho independente do tamanho do armazenamento do disco. Assim, é possível otimizar o desempenho do banco de dados e pagar apenas pelos recursos de entrada/saída (E/S) necessários para sua carga de trabalho. Se o pool de buffers de um banco de dados MySQL for maior que o conjunto de trabalho, durante as operações de estado estável, ele poderá atender a quase todas as consultas de leitura do pool de buffers, sem tocar no disco.

Para selecionar um nível de desempenho para seu volume do Hyperdisk, considere sua carga de trabalho de gravação do MySQL, com ênfase especial no seguinte:

  • Acesso aos registros de refazer InnoDB
  • Atualizações subsequentes de arquivos de dados e índices InnoDB

Fora das operações de estado estável, os eventos de manutenção do banco de dados também podem causar um desempenho de disco mais instável. A frequência com que isso ocorre tende a aumentar com a carga de trabalho de gravação do banco de dados. Portanto, é mais provável em situações como recuperação pós-falha usando registros de refazer ou um sistema de backup que se copia lendo todas as mudanças no banco de dados desde o último backup.

Dimensionar o disco

Há três estratégias comuns para dimensionar os limites de desempenho do disco:

  1. Use a configuração padrão. Cada disco vem com pelo menos 3.000 operações de entrada/saída por segundo (IOPS) e 140 MiBps de capacidade de processamento. Isso é suficiente para cargas de trabalho básicas do MySQL e volumes de inicialização do sistema operacional (SO). Se o caso de uso crescer além disso, você poderá modificar a performance de E/S provisionada sob demanda sem interromper a carga de trabalho.
  2. Meça seu uso atual. Se o banco de dados já estiver sendo executado em outro ambiente, registre as IOPS e a capacidade de transferência do disco com uma granularidade de um minuto ou menos. Depois de ter uma ou duas semanas de dados, para que seu conjunto de amostras inclua alguma flutuação na carga e eventos normais de manutenção, selecione um valor de percentil alto desse conjunto de dados e adicione um pequeno buffer para considerar o crescimento orgânico ou o uso inesperado.
  3. Estime suas necessidades e modifique-as depois. Se você não tiver uma fonte de dados, talvez seja necessário estimar suas necessidades de performance inicialmente e depois ajustar os valores após a implantação. Recomendamos provisionar um valor maior do que você acha que vai precisar inicialmente para que sua carga de trabalho não encontre gargalos de desempenho e, eventualmente, reduzir o desempenho provisionado para se adequar à sua carga de trabalho.

Aumentar a performance do disco

É possível aumentar o desempenho de cada disco do Hyperdisk Balanced até um máximo de 160.000 IOPS e 2.400 MBps de capacidade de processamento. O tamanho da VM ajuda a determinar os limites máximos de desempenho do Hyperdisk. Portanto, se você quiser um desempenho muito alto do Hyperdisk, talvez seja necessário aumentar o número de núcleos da VM. Se as cargas de trabalho mais exigentes precisarem de um desempenho de disco maior do que um único disco Hyperdisk Balanced pode oferecer, use um dos seguintes métodos para fazer o striping de vários discos Hyperdisk Balanced:

  • Fazer upgrade para o Hyperdisk Extreme
  • Use um mecanismo de software diferente para matriz redundante de discos independentes (RAID), como mdadm.

À medida que você escalona seus bancos de dados MySQL, é possível aumentar dinamicamente a capacidade e o desempenho dos discos sem inatividade. Isso ajuda no desempenho de cargas de trabalho de processamento analítico on-line (OLAP) que fazem junções grandes e complexas que não cabem na RAM e são transferidas para o disco. Em casos raros, as cargas de trabalho do MySQL que exigem latência de armazenamento extremamente baixa e toleram perda de dados podem armazenar o conjunto de dados completo em um SSD local. Você também pode usar as seguintes soluções híbridas para melhorar a latência de leitura e limitar as reduções na durabilidade:

  • Espelhe seu conjunto de dados entre um hiperdisco e um SSD local.
  • Use um gerenciador de volumes para configurar o SSD local como um cache de dados armazenados em um Hyperdisk subjacente.

Aproveitar outros recursos do Hyperdisk

O Hyperdisk também oferece os seguintes recursos, que podem aumentar ou simplificar os fluxos de trabalho de alta disponibilidade e recuperação de desastres locais:

Para mais informações sobre como configurar esses recursos com o MySQL para Compute Engine, consulte a seção alta disponibilidade a seguir nesta página.

SSDs locais

Algumas famílias de máquinas do Compute Engine permitem usar SSDs locais em vez do Hyperdisk. Eles não são armazenamento durável, mas as cargas de trabalho do MySQL geralmente os usam para armazenar tablespaces temporários.

Para informações sobre como usar SSDs locais para escalonar bancos de dados MySQL, consulte Redimensionamento dinâmico de disco, que está nesta página.

Outros recursos do Compute Engine

Use os seguintes recursos do Compute Engine para otimizar sua implantação do MySQL.

Cloud Monitoring

Para monitorar o desempenho da VM e o uso dos serviços de infraestrutura, use o consoleGoogle Cloud . Na página Instâncias de VM, na guia Observabilidade, é possível monitorar métricas relacionadas à performance, como utilização de CPU e memória, largura de banda da rede e performance provisionada das instâncias. Da mesma forma, na página Discos, na guia Observabilidade, é possível monitorar a capacidade de processamento e as IOPS dos volumes de disco.

Para personalizar as métricas de desempenho que você vê, use o Cloud Monitoring para criar consultas. É possível selecionar as métricas de desempenho específicas que você quer ver para os serviços de infraestrutura. Para métricas específicas do MySQL, o Compute Engine oferece um plug-in de carga de trabalho do MySQL.

Práticas recomendadas para configurar o sistema operacional

  • Use um sistema de arquivos adequado. O Google se concentra na otimização para os sistemas de arquivos ext4 e XFS do Linux. No entanto, a maioria dos sistemas de arquivos é adequada para uso com o MySQL.
  • Desative as huge pages transparentes (THP) na configuração do sistema operacional de base. Para saber como desativar o THP, consulte a documentação do THP.
  • Se você estiver usando o Linux, use as flags relatime e lazytime para a configuração de montagem do sistema de arquivos. Isso reduz os custos de performance associados à atualização dos valores atime, mtime e ctime em arquivos quando eles são lidos, modificados ou têm os metadados alterados.

Práticas recomendadas para configurar o MySQL

Recomendamos que você use as seguintes configurações de configuração para o MySQL.

  • Use uma versão recente do MySQL. O Google se concentra na otimização para o MySQL versão 8.0 e versões mais recentes.

  • Aumente o tamanho do pool de buffers. O MySQL usa o pool de buffer para melhorar o desempenho de leitura armazenando dados em cache na RAM, o que reduz os acessos ao disco. Por padrão, o tamanho do pool de buffer do MySQL é de 128 MiB, o que é muito pequeno para a maioria dos casos de uso práticos. Recomendamos que você aumente o tamanho de innodb_buffer_pool_size para que seja maior que o tamanho do conjunto de trabalho que seu aplicativo acessa no banco de dados. Isso geralmente consiste nas seguintes etapas:

    1. Meça ou estime o tamanho do seu conjunto de trabalho em uma cópia em execução da instância do MySQL.
    2. Escolha um tamanho e um formato de máquina virtual (VM) com RAM suficiente para acomodar esse conjunto de trabalho.
    3. Configure o tamanho do pool de buffers na VM para ocupar a maior parte da RAM disponível.

  • Ative o buffer de gravação dupla. O MySQL tem um buffer de gravação dupla (link em inglês) que ajuda a proteger contra gravações incompletas (link em inglês), um modo de falha em que uma gravação que abrange vários blocos no disco pode ser parcialmente confirmada se ocorrer uma falha de hardware ou de energia no meio da gravação. Para aproveitar essa proteção, ative o innodb_doublewrite.

  • Defina o valor de innodb_flush_log_at_trx_commit como 1. Isso garante que as transações de gravação sejam duráveis no disco quando forem confirmadas.

  • Para reduzir a sobrecarga de performance, especifique um valor para innodb_flush_method. Para o MySQL versão 8.0.14 e mais recentes, defina o valor de innodb_flush_method como O_DIRECT_NO_FSYNC, que é ideal, mas só está presente nessas versões. Para versões do MySQL anteriores à 8.0.14, defina o valor de innodb_flush_method como O_DIRECT.

  • Em cenários de replicação de alta disponibilidade, defina o valor de sync_binlog da instância de banco de dados principal como 1. O MySQL usa o registro binário para comunicar mudanças do banco de dados principal para o secundário. Isso garante que os registros binários sejam confirmados no momento da confirmação da transação, com o menor atraso de replicação e objetivo de ponto de recuperação (RPO) possível entre os bancos de dados.

  • Ao usar o MySQL em famílias de máquinas da série C, ative innodb_numa_interleave. Isso garante que o pool de buffers do MySQL possa aproveitar as políticas de acesso à memória não uniforme (NUMA).

Quando desativar o buffer de gravação dupla

O buffer de gravação dupla do MySQL, que protege contra gravações interrompidas, tem uma sobrecarga de desempenho de até 25% para transações de gravação do MySQL, o que pode afetar a latência da transação. O Google Cloud Hyperdisk também oferece proteção contra gravação incompleta. Portanto, se você estiver usando o MySQL para gravar diretamente em um sistema de arquivos ext4 executado no Hyperdisk, poderá desativar com segurança o buffer de gravação dupla.

No entanto, para que a proteção contra gravação incompleta do Hyperdisk seja eficaz, configure o sistema de arquivos e outras camadas de software intermediárias entre o banco de dados e o disco para evitar a introdução de gravações incompletas acima da camada de disco. A lista a seguir fornece exemplos de configurações que podem introduzir gravações corrompidas acima da camada do Hyperdisk:

  • Executar a instância do MySQL em contêineres, como o Google Kubernetes Engine ou o Kubernetes auto-hospedado.
  • Armazenar os arquivos do MySQL em um sistema de arquivos XFS, que não é compatível com tamanhos de bloco grandes o suficiente na maioria das configurações do kernel do Linux.
  • Armazenar seus arquivos do MySQL em uma configuração de matriz redundante de discos independentes (RAID) que causa o striping de disco, como mdadm para Linux ou Espaços de armazenamento e Espaços de armazenamento direto para Windows.
  • Armazenar seus arquivos do MySQL em um gerenciador de volumes, como o Logical Volume Manager (LVM) para Linux ou Espaços de armazenamento e Espaços de armazenamento direto para Windows.

  • Armazenar seus arquivos do MySQL no Hyperdisk com uma unidade de estado sólido (SSD) local configurada como um cache, como usar lvmcache, dm-cache ou bcache para Linux ou Espaços de armazenamento para Windows.

  • Executar a instância do MySQL em uma VM usando a virtualização aninhada.

Embora seja possível configurar as configurações anteriores para que elas não introduzam gravações corrompidas, não recomendamos desativar o buffer de gravação dupla ao usá-las devido à dificuldade de validar se uma determinada configuração é segura.

(Opcional) Desativar o buffer de gravação dupla

Para desativar o buffer de gravação dupla, siga estas etapas:

  1. No sistema de arquivos ext4, ative o recurso bigalloc e configure o tamanho do cluster do sistema de arquivos como 16KiB ou um múltiplo de potência de 2 maior que 16KiB. Isso garante que as gravações do MySQL não sejam divididas em E/S separadas pelo sistema de arquivos antes de serem emitidas para o Hyperdisk. Não aumentar o limite ou usar um valor menor que 16 KiB não protege contra gravações corrompidas. Como exemplo com tamanho de cluster de 16 KiB, isso é configurado no momento da criação do sistema de arquivos:

    mkfs.ext4 -O bigalloc -C 16384 /dev/<device-name>

  2. Desative innodb_doublewrite e defina innodb_flush_method como O_DIRECT ou O_DIRECT_NO_FSYNC (dependendo da sua versão do MySQL, conforme descrito acima).

Configurar alta disponibilidade (HA) e uma solução de backup

Recomendamos que você proteja todas as suas cargas de trabalho críticas do MySQL configurando soluções de alta disponibilidade (HA) e backup para elas. Para HA e backup, os seguintes fatores são os mais importantes:

As soluções de alta disponibilidade geralmente têm como meta RTO e RPO próximos de zero, mas protegem apenas contra falhas de infraestrutura. As soluções de backup têm como alvo janelas de RTO e RPO mais longas, mas oferecem cobertura para um conjunto maior de cenários de falha, como:

  • Exclusão acidental de dados
  • Ataques de ransomware
  • Desastres naturais

Configurar alta disponibilidade (HA)

Os recursos de HA usam redundância de armazenamento e computação para garantir que seu banco de dados MySQL tenha tempo de inatividade reduzido em caso de falha ou interrupção do host, permitindo que aplicativos cliente acessem os dados mesmo quando uma instância ou zona está indisponível.

O MySQL permite a replicação nos seguintes modos:

  • Modo assíncrono. No modo assíncrono, o primário reconhece as transações de gravação assim que elas são confirmadas localmente. Portanto, se houver uma interrupção no primário, uma pequena quantidade de dados gravados recentemente poderá ser perdida durante o failover, já que o RPO é próximo de zero, mas não é zero.
  • Modo semissíncrono. No modo semissíncrono, a primária aguarda para reconhecer a transação até que um número configurável de réplicas tenha reconhecido o recebimento da transação. Isso aumenta muito a chance de não haver perda de dados durante um failover não planejado, já que o RPO é efetivamente zero.

Nos dois modos, o RTO é determinado pela rapidez com que as verificações de integridade fazem o seguinte:

  1. Identifique uma instância com falha.
  2. Acione o failover.
  3. Notifique os clientes de que a instância de failover agora é a principal usando o Sistema de Nomes de Domínio (DNS) ou outra forma de identificar o servidor de banco de dados.

Em qualquer modo de replicação, é necessário ter uma instância de failover para replicar. É possível localizar essa instância em qualquer um dos seguintes locais:

  • A mesma zona em que a instância principal está localizada
  • Uma zona diferente na região em que a instância principal está localizada
  • Uma região diferente da principal

Para manter a alta disponibilidade mesmo durante falhas temporárias zonais, recomendamos a seguinte configuração:

  • Localize as instâncias principal e de failover em zonas diferentes,estejam ou não na mesma região.
  • Use a replicação assíncrona. Isso porque, se você estiver usando replicação semissíncrona, localizar as instâncias principal e de failover em zonas separadas pode causar alta latência para confirmações de transações de gravação.
  • Se você precisar de RPO zero, use o Hyperdisk equilibrado de alta disponibilidade, que permite replicar um disco de forma síncrona em duas zonas na mesma região. Para mais detalhes, consulte o guia do Google sobre como fornecer serviços de alta disponibilidade usando o Hyperdisk High Availability. Ao configurar o Hyperdisk Balanced High Availability, recomendamos a integração com grupos de instâncias gerenciadas com estado para diagnosticar problemas de integridade da instância e automatizar ações de recuperação.

Configurar um plano de backup e resiliência de dados

Os planos de backup e resiliência de dados ajudam a evitar a perda de dados durante falhas como exclusão acidental de dados, ataques de ransomware e desastres naturais. Também é possível usá-los como armazenamento de acesso raro para requisitos de conformidade e auditoria. Para o MySQL, há muitas metodologias de backup para escolher, algumas das quais atuam no nível do banco de dados e outras no nível do volume de armazenamento. Ao selecionar uma metodologia, considere principalmente os requisitos de RTO e RPO.

Backup no nível do banco de dados

Para backups no nível do banco de dados, considere usar as seguintes opções fornecidas pelo MySQL:

  • Backups incrementais baseados em geração de registros binários,que criam despejos de dados lógicos. Isso inclui o seguinte:
  • Ferramentas que gerenciam o processo de backup para você,como o MySQL Enterprise Backup.

Para mais informações sobre as opções de backup no nível do banco de dados do MySQL, consulte Backup e recuperação na documentação do MySQL.

Para qualquer uma dessas opções, você precisa ter um sistema de armazenamento secundário para copiar os dados de backup. Recomendamos as seguintes ferramentas:

Use o Hyperdisk para criar snapshots e clones no nível de armazenamento

Para backups no nível de armazenamento, recomendamos usar produtos Hyperdisk para criar snapshots, clonar e capturar uma visualização pontual do seu banco de dados MySQL. O RPO dessa abordagem depende da frequência com que você faz snapshots do banco de dados, e o RTO depende da solução específica usada.

Se a recuperação rápida for importante para você e você só precisar de cobertura de backup em uma zona, recomendamos usar os snapshots instantâneos da Hyperdisk. Os instant snapshots capturam dados em um momento específico de forma incremental e podem restaurar rapidamente os dados para um novo volume do Hyperdisk usando a clonagem de disco, oferecendo um RTO de minutos. Eles permitem recuperar dados quando o conteúdo de um disco foi substituído, excluído ou corrompido e estão disponíveis localmente na mesma zona ou região do disco de origem. Para mais informações, consulte Sobre os Instant Snapshots

Para cenários de recuperação de desastres, em que os dados precisam ser armazenados com maior redundância do que o disco original e em um local separado para garantir que um único desastre não afete todas as réplicas dos dados, recomendamos o uso de snapshots de disco padrão e de arquivamento do Hyperdisk. Os snapshots de disco padrão e de arquivamento criam uma cópia dos dados no disco em um determinado momento e a armazenam com alta redundância em um formato imutável. Quando você cria vários snapshots de um disco, como com uma programação de snapshots, o Hyperdisk armazena apenas mudanças incrementais. Os snapshots de disco padrão e de arquivo são adequados se você puder tolerar um RTO mais alto, porque a cópia de dados do armazenamento de snapshots de volta para o armazenamento de VM pode significar que eles levam mais tempo para serem restaurados. Para mais informações, consulte Criar snapshots de disco padrão e de arquivamento.

Os snapshots instantâneos do Hyperdisk e os snapshots padrão e de arquivo são consistentes em caso de falha em um único disco. Isso significa que, ao restaurar de um snapshot, seu banco de dados MySQL precisa executar as etapas normais de recuperação do InnoDB para trazer os arquivos de dados e de registros de volta a um estado consistente. Dependendo da configuração do seu log de refazer do InnoDB, isso pode aumentar o RTO. Os padrões a seguir podem complicar ainda mais seus esforços para criar um snapshot consistente do banco de dados:

  • Os arquivos do banco de dados MySQL estão espalhados por vários volumes.
  • Você está usando utilitários de RAID de software do Linux, como mdadm.
  • Você separou os locais de armazenamento configurados do MySQL em sistemas de arquivos em discos diferentes.

Para criar um snapshot que não exija recuperação após uma restauração, siga estas etapas:

  1. Bloqueie temporariamente o acesso de gravação ao banco de dados MySQL.
  2. Despeje todos os buffers em andamento no disco usando os comandos LOCK INSTANCE FOR BACKUP e FLUSH TABLES WITH READ LOCK.
  3. Inicie as operações de snapshot.

  4. Para cenários com vários discos, depois de liberar no nível do MySQL, execute os comandos sync e fsfreeze no servidor para liberar todas as gravações em andamento no disco e pausar novas gravações recebidas no nível do sistema de arquivos.

Depois de capturar o snapshot inicial do banco de dados, não é necessário continuar bloqueando o disco, porque o Hyperdisk captura rapidamente a visualização pontual e pode processar de forma assíncrona as etapas subsequentes de cópia de armazenamento. Se você precisar dessas etapas para consistência de snapshot e quiser remover esse impacto de gravação no banco de dados principal, também poderá executar o backup em uma réplica de banco de dados em vez do banco de dados principal.

A seguir