Configurar o MySQL no Compute Engine

O Compute Engine oferece vários tipos de instâncias e opções de armazenamento para ler e gravar dados nos seus bancos de dados MySQL. Para garantir o melhor desempenho e custo para suas cargas de trabalho de banco de dados, recomendamos a execução em produtos de infraestrutura como serviço (IaaS) de última geração.

As recomendações de configuração a seguir consideram que as cargas de trabalho do MySQL são usadas com frequência em sistemas de leitura pesada, como processamento de transações on-line (OLTP, na sigla em inglês) ou o banco de dados que oferece suporte a um aplicativo da Web típico. Eles também consideram escolhas 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 ao desempenho, talvez seja necessário ajustar as configurações. Recomendamos usar este guia como ponto de partida para a implantação e, em seguida, testar com a carga de trabalho real para validar se a configuração atende às suas necessidades.

Escolha sua máquina virtual (VM)

Para cargas de trabalho do MySQL, recomendamos usar a geração mais recente de famílias de máquinas C e N, porque elas incluem formas 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 Trusted Cloud by S3NS postagem do blog (em inglês). Essas famílias de máquinas usam Titanium e são baseadas em gerações recentes de processadores Intel, AMD e Axion.

Foco na performance

Para cargas de trabalho sensíveis ao desempenho, como bancos de dados MySQL essenciais para os negócios, recomendamos as instâncias C4 e C4A mais recentes, se estiverem disponíveis na sua região. Se não for possível acessá-los, 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 de computação e incluem os seguintes recursos úteis para cargas de trabalho focadas em desempenho:

  • Controle os 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 de 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 prioridade principal é otimizar custos, 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 última geração do Compute Engine para otimizar o custo total e manter uma performance sólida, sem as garantias fortes que o C4, C4A, C3 e C3D oferecem. Para mais detalhes, consulte Gerenciamento de recursos dinâmicos de última geração.

Configurar o tamanho da VM

Para qualquer VM que você usa, é importante escolher o tamanho certo para o nível de desempenho do MySQL que você almeja.

Se você quer uma alta taxa 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 mais adiante nesta página.

Se você quiser uma alta performance de consultas de leitura por segundo (QPS), recomendamos usar o pool de buffer baseado em RAM do MySQL para armazenar dados em cache e reduzir as 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 o banco de dados processa de uma só vez, caiba no pool de buffers.
  • Dimensione o pool de buffer para usar a maior parte da RAM na VM.

Para minimizar o custo de dimensionamento da 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 para a maioria das cargas de trabalho do MySQL, determine o conjunto de trabalho da carga de trabalho e escolha a menor forma de instância highmem que se encaixa nesse conjunto de trabalho na RAM. As formas de instância highmem têm cerca de 8 GB de RAM por vCPU. Isso dá a você memória suficiente para armazenar em cache um conjunto de trabalho grande, mantendo uma CPU suficiente para lidar com uma carga de consulta alta.

Para cargas de trabalho com conjuntos de trabalho grandes, mas taxas de consulta baixas, usando instâncias N4, é possível otimizar ainda mais o custo total usando tipos de máquina personalizados com memória estendida para aumentar ainda mais a proporção de RAM para vCPU.

Configurar a largura de banda de rede da VM

Para a maioria dos casos de uso do MySQL, você pode usar os limites de largura de banda de rede padrão para sua instância. Se isso atender às suas necessidades, não será necessário fazer upgrade para redes 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 Balanceado é 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 equilibrado 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 o nível de performance

Com o Hyperdisk equilibrado, você seleciona o nível de desempenho independentemente do tamanho de 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 a carga de trabalho. Se o pool de buffer de um banco de dados MySQL for maior que o conjunto de trabalho, ele poderá atender a quase todas as consultas de leitura do pool de buffer durante operações em estado estável, sem tocar no disco.

Para selecionar um nível de desempenho para o volume do Hyperdisk, considere a carga de trabalho de gravação do MySQL, com ênfase especial nos seguintes pontos:

  • Acesso a registros de repetição de InnoDB
  • Atualizações subsequentes nos arquivos de dados e índices InnoDB

Fora das operações em estado estável, os eventos de manutenção do banco de dados também podem causar uma performance mais instável do disco. 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 que isso ocorra em situações como recuperação pós-falha usando registros de repetição ou um sistema de backup que se copia lendo todas as alterações do 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 entradas/saídas por segundo (IOPS) e 140 MiBps de capacidade. Isso é suficiente para cargas de trabalho básicas do MySQL e volumes de inicialização do sistema operacional (SO). Se o caso de uso ultrapassar esse limite, 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 em execução em outro ambiente, registre as IOPS e a capacidade do disco com granularidade de um minuto ou menos. Depois de uma ou duas semanas de dados, para que o conjunto de amostras inclua algumas flutuações nos eventos de carga e manutenção normais, 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 ajustá-las após a implantação. Recomendamos provisionar um valor maior do que você acha que vai precisar inicialmente para que a carga de trabalho não encontre gargalos de desempenho e, em seguida, reduzir a performance provisionada para se adequar à 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 uma performance muito alta 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 equilibrado pode oferecer, use um dos métodos a seguir para agrupar vários discos Hyperdisk equilibrados:

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

Ao dimensionar seus bancos de dados MySQL, você pode aumentar dinamicamente a capacidade e o desempenho dos discos sem inatividade. Isso ajuda a performance de cargas de trabalho do estilo processamento analítico on-line (OLAP, na sigla em inglês) a fazer grandes mesclagens 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 uma latência de armazenamento extremamente baixa e toleram a perda de dados podem armazenar o conjunto de dados completo no 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 volume para configurar o SSD local como um cache para dados armazenados em um Hyperdisk.

Aproveite 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 local:

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 o uso de 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 aparece a seguir nesta página.

Outros recursos do Compute Engine

Você pode usar os recursos do Compute Engine a seguir para otimizar a implantação do MySQL.

Cloud Monitoring

Para monitorar o desempenho da VM e o uso dos serviços de infraestrutura, use o consoleTrusted Cloud . Na página Instâncias de VM, na guia Observabilidade, é possível monitorar métricas relacionadas ao desempenho, como a utilização da CPU e da memória, a largura de banda de rede e a 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 exibidas, use o Cloud Monitoring para criar consultas. É possível selecionar as métricas de performance específicas que você quer ver para seus 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 páginas transparentes (THP) na configuração do sistema operacional básico. 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 desempenho 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 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 mais recentes.

  • Aumente o tamanho do pool de buffer. O MySQL usa o pool de buffer para melhorar o desempenho de leitura armazenando dados em cache na RAM, reduzindo as solicitações de 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 aumentar o tamanho de innodb_buffer_pool_size para que seja maior que o tamanho do conjunto de trabalho que o aplicativo acessa no banco de dados. Isso geralmente consiste nas seguintes etapas:

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

  • Ative o buffer de gravação dupla. O MySQL tem um buffer de gravação dupla que ajuda a proteger contra gravações rasgadas, um modo de falha em que uma gravação que abrange vários blocos no disco pode ser parcialmente confirmada se uma falha de hardware ou de energia ocorrer no meio da gravação. Para aproveitar essa proteção, ative 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 desempenho, 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 é o ideal, mas está disponível apenas 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 da sync_binlog da instância do banco de dados principal para 1. O MySQL usa o registro binário para comunicar as mudanças do banco de dados principal ao 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 buffer do MySQL possa aproveitar as políticas de acesso a memória não uniforme (NUMA, na sigla em inglês).

Quando desativar o buffer de gravação dupla

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

No entanto, para que a proteção contra gravação rasgada do Hyperdisk seja eficaz, é necessário configurar 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 rasgadas acima da camada do disco. A lista a seguir mostra exemplos de configurações que podem introduzir gravações rasgadas acima da camada do Hyperdisk:

  • Executar sua instância do MySQL em contêineres, como o Google Kubernetes Engine ou o Kubernetes auto-hospedado.
  • Armazenar arquivos do MySQL em um sistema de arquivos XFS, que não oferece suporte a tamanhos de bloco grandes o suficiente na maioria das configurações do kernel do Linux.
  • Armazenar arquivos do MySQL em uma matriz redundante de configuração de discos independentes (RAID, na sigla em inglês) que causa o striping de disco, como mdadm para Linux ou Storage Spaces e Storage Spaces Direct para Windows.
  • Armazenar seus arquivos MySQL em um gerenciador de volume, como o Logical Volume Manager (LVM) para Linux ou Storage Spaces e Storage Spaces Direct para Windows.

  • Armazenar arquivos MySQL no Hyperdisk com unidade de estado sólido (SSD) local configurada como um cache, como o uso de 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) Desative o buffer de gravação dupla

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

  1. No sistema de arquivos ext4, é necessário ativar o recurso bigalloc e configurar o tamanho do cluster do sistema de arquivos como 16 KiB ou um valor maior de 2 elevado à potência de 16. 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 qualquer valor menor que 16 KiB não protege contra gravações rasgadas. Como exemplo, com um 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 cargas de trabalho essenciais do MySQL configurando alta disponibilidade (HA, na sigla em inglês) e soluções de backup para elas. Para HA e backup, os seguintes fatores são os mais importantes:

As soluções de HA geralmente têm como alvo RTO e RPO próximos de zero, mas protegem apenas contra falhas na 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 estes:

  • 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 o banco de dados MySQL tenha tempo de inatividade reduzido no caso de falha ou interrupção do host, permitindo que os 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 está próximo de zero, mas não é zero.
  • Modo semi-síncrono. No modo semi-síncrono, a primária aguarda para confirmar a transação até que um número configurável de réplicas tenha confirmado o recebimento da transação. Isso aumenta muito a chance de que não ocorra perda de dados durante um failover não planejado, já que o RPO é efetivamente zero.

Para os 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. Acionar 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. Você pode localizar essa instância em qualquer um dos seguintes locais:

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

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

  • Localize as instâncias primária e de failover em zonas diferentes,mesmo que estejam na mesma região.
  • Use a replicação assíncrona. Isso ocorre porque, se você estiver usando a replicação semi-síncrona, localizar as instâncias principal e de failover em zonas separadas pode causar alta latência para confirmações de transação 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. No MySQL, há muitas metodologias de backup para escolher, algumas delas atuam no nível do banco de dados e outras no nível do volume de armazenamento. Ao selecionar uma metodologia, você precisa considerar principalmente seus requisitos de RTO e RPO.

Fazer backup no nível do banco de dados

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

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

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, é necessário ter um sistema de armazenamento secundário para copiar os dados de backup. Recomendamos as seguintes ferramentas:

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

Para backups no nível do armazenamento, recomendamos usar os produtos do Hyperdisk para fazer 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 seu banco de dados, e o RTO depende da solução específica que você usa.

Se a recuperação rápida for importante para você e você precisar apenas de cobertura de backup em uma zona, recomendamos o uso dos snapshots instantâneos do Hyperdisk. Os snapshots instantâneos 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 que você recupere dados quando o conteúdo de um disco for substituído, excluído ou corrompido e estiver disponível 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 que você use o arquivo e os snapshots de disco padrão do Hyperdisk. Os snapshots de arquivamento e padrão do disco criam uma cópia dos dados no disco em um determinado momento e os 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 uma boa opção se você puder tolerar um RTO maior, porque a cópia de dados do armazenamento de snapshots para o armazenamento de VMs pode significar que eles levam mais tempo para ser 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 com falhas em um único disco. Isso significa que, ao restaurar de um snapshot, o banco de dados MySQL precisa executar as etapas normais de recuperação do InnoDB para retornar os registros e arquivos de dados a um estado consistente. Dependendo da configuração do registro de repetição do InnoDB, isso pode aumentar o RTO. Os padrões a seguir podem complicar ainda mais seus esforços para criar um snapshot de banco de dados consistente:

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

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

  1. Bloqueie temporariamente o acesso de gravação ao banco de dados MySQL.
  2. Esvazie todos os buffers em andamento para o 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 limpar no nível do MySQL, execute os comandos sync e fsfreeze no servidor para limpar todas as gravações em andamento no disco e pausar novas gravações de entrada no nível do sistema de arquivos.

Depois de capturar o snapshot inicial do banco de dados, não é necessário continuar travando o disco, porque o Hyperdisk captura rapidamente a visualização pontual e pode processar de forma assíncrona todas as etapas de cópia de armazenamento posteriores. Se você precisar dessas etapas para a consistência do 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