Configure o MySQL no Compute Engine

O Compute Engine oferece uma variedade de tipos de instâncias e opções de armazenamento diferentes para ler e escrever dados das suas bases de dados MySQL. Para garantir que atinge o melhor desempenho e custo para as suas cargas de trabalho de base de dados, recomendamos a execução em produtos de infraestrutura como serviço (IaaS) de nova geração.

As seguintes recomendações de configuração têm em conta que as cargas de trabalho do MySQL são frequentemente usadas em sistemas com muitas leituras, como o processamento de transações online (OLTP) ou a base de dados que suporta uma aplicação Web típica. Também têm em conta as escolhas de configuração comuns, como a utilização da versão 8.0 ou posterior do MySQL e a utilização do motor de armazenamento InnoDB. Para cargas de trabalho sensíveis ao desempenho, pode ter de ajustar as configurações para se adequarem. Recomendamos que use este guia como ponto de partida para a sua implementação e, em seguida, teste com a sua carga de trabalho real para validar se a configuração satisfaz as suas necessidades.

Escolha a sua máquina virtual (VM)

Para cargas de trabalho do MySQL, recomendamos que use a geração mais recente das famílias de máquinas C e N, uma vez que incluem formatos que funcionam bem para a maioria das configurações práticas do MySQL. Para uma introdução a estas séries de máquinas, consulte a seguinte Google Cloud publicação no blogue. Estas famílias de máquinas usam o Titanium e baseiam-se nas gerações recentes de processadores Intel, AMD e Axion.

Foco no desempenho

Para cargas de trabalho sensíveis ao desempenho, como bases de dados MySQL críticas para a empresa, recomendamos as instâncias C4 e C4A mais recentes, se estiverem disponíveis na sua região. Se não conseguir aceder a elas, as instâncias C3 e C3D oferecem um foco semelhante no desempenho.

Estas instâncias oferecem a latência mais baixa e consistente para operações limitadas por computação e incluem as seguintes funcionalidades úteis para cargas de trabalho focadas no desempenho:

  • Controlo sobre eventos de manutenção do anfitrião com notificação antecipada
  • Controlo da otimização turbo de núcleo único para maior consistência do desempenho
  • Redes de nível 1 para uma largura de banda de rede mais elevada

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

Otimize em função do custo

Para cargas de trabalho em que a sua prioridade principal é otimizar o custo, como bases de dados MySQL com níveis de tráfego baixos a médios ou bases de dados usadas em ambientes de teste ou desenvolvimento, recomendamos que use as instâncias N4 mais recentes. Estas instâncias usam a próxima geração da gestão dinâmica de recursos do Compute Engine para otimizar o custo total, mantendo um desempenho sólido, sem as fortes garantias que as instâncias C4, C4A, C3 e C3D oferecem. Para mais detalhes, consulte o artigo Gestão dinâmica de recursos de nova geração.

Configure o tamanho da VM

Para qualquer MV que usar, é importante escolher o tamanho certo da MV para o nível de desempenho do MySQL que pretende alcançar.

Se estiver a tentar alcançar um elevado desempenho de transações de escrita por segundo (TPS), o principal fator a considerar é o armazenamento em bloco. Para mais detalhes, consulte o artigo Configure o armazenamento em blocos, que se segue nesta página.

Se pretende alcançar um elevado desempenho de consultas de leitura por segundo (QPS), recomendamos vivamente que use o conjunto de buffers baseado em RAM do MySQL para colocar em cache dados frequentes e reduzir os acessos ao disco. Para maximizar estas vantagens, siga os passos abaixo:

  • Escolha um tamanho de VM que garanta que o conjunto de trabalho, ou a quantidade total de dados que a sua base de dados processa de uma só vez, se ajusta ao conjunto de memória intermédia.
  • Dimensionar o conjunto de buffers para usar a maior parte da RAM na VM.

Para minimizar o custo de dimensionar a sua VM desta forma, recomendamos que use uma VM com uma proporção elevada de RAM para CPUs virtuais (vCPUs), para evitar pagar por vCPUs que não usa.

Para um equilíbrio ideal para a maioria das cargas de trabalho do MySQL, determine o conjunto de trabalho da sua carga de trabalho e, em seguida, escolha a forma de instância highmem mais pequena que se ajuste a esse conjunto de trabalho na RAM. As formas de instâncias highmem têm cerca de 8 GB de RAM por vCPU. Isto dá-lhe memória suficiente para armazenar em cache um grande conjunto de trabalho, ao mesmo tempo que mantém CPU suficiente para processar uma carga de consultas elevada.

Para cargas de trabalho com grandes conjuntos de trabalho, mas taxas de consultas baixas, pode usar instâncias N4 para otimizar ainda mais o custo total usando tipos de máquinas personalizados com memória expandida para aumentar ainda mais a proporção de RAM para vCPU.

Configure a largura de banda da rede da sua VM

Para a maioria dos exemplos de utilização do MySQL, pode manter os limites de largura de banda da rede predefinidos para a sua instância. Se esta opção satisfizer as suas necessidades, não precisa de atualizar para a rede Tier_1.

Configure o armazenamento em bloco

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

Google Cloud Hyperdisk

O Hyperdisk Balanced oferece as seguintes funcionalidades:

  • Latência do SSD a baixo custo
  • Configurações de elevado desempenho para aplicações que precisam delas
  • Durabilidade superior a 99,999% para proteção contra o risco de falha de hardware e corrupção de dados silenciosa em toda a indústria
  • Encriptação de todos os dados do Hyperdisk em repouso com chaves de encriptação geridas pela Google ou pelo cliente

Selecione o seu nível de desempenho

Com o Hyperdisk Balanced, seleciona o nível de desempenho independentemente do tamanho do armazenamento do disco, para que possa otimizar o desempenho da sua base de dados enquanto paga apenas pelos recursos de entrada/saída (E/S) de que a sua carga de trabalho precisa. Se o conjunto de buffers de uma base de dados MySQL for maior do que o respetivo conjunto de trabalho, durante as operações de estado estável, pode processar quase todas as consultas de leitura a partir do conjunto de buffers, sem aceder ao disco.

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

  • Acesso aos InnoDB registos de refazer
  • Atualizações subsequentes aos InnoDB ficheiros de dados e índices

Fora das operações em estado estacionário, os eventos de manutenção da base de dados também podem causar um desempenho do disco mais instável. A frequência com que isto ocorre tende a aumentar com a carga de trabalho de escrita da base de dados, pelo que é mais provável em situações como a recuperação após falhas com registos de repetição ou um sistema de cópia de segurança que se copia a si próprio lendo todas as alterações da base de dados desde a última cópia de segurança.

Defina o tamanho do disco

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

  1. Use a configuração predefinida. Cada disco inclui, pelo menos, 3000 operações de entrada/saída por segundo (IOPS) e 140 MiBps de débito. Isto é suficiente para cargas de trabalho básicas do MySQL e volumes de arranque do sistema operativo (SO). Se o seu exemplo de utilização ultrapassar este limite, pode modificar o desempenho de E/S aprovisionado a pedido sem parar a carga de trabalho.
  2. Meça a sua utilização existente. Se a sua base de dados já estiver a ser executada noutro ambiente, registe os IOPS e o débito do disco com uma granularidade de um minuto ou menos. Depois de ter uma a duas semanas de dados, para que o conjunto de amostras inclua alguma flutuação na carga e eventos de manutenção normais, selecione um valor de percentil elevado desse conjunto de dados e adicione um pequeno buffer para ter em conta o crescimento orgânico ou a utilização inesperada.
  3. Estime as suas necessidades e, em seguida, modifique-as mais tarde. Se não tiver uma origem de dados existente, pode ter de estimar inicialmente as suas necessidades de desempenho e, em seguida, ajustá-las após a implementação. Recomendamos que disponibilize um valor superior ao que considera necessário inicialmente, para que a sua carga de trabalho não encontre gargalos de desempenho e, em seguida, reduza o desempenho disponibilizado para se adequar à sua carga de trabalho.

Aumente o desempenho do disco

Pode aumentar o desempenho de cada disco Hyperdisk Balanced até um máximo de 160 000 IOPS e 2400 MBps de débito. A dimensão da VM ajuda a determinar os limites máximos de desempenho do Hyperdisk. Por isso, se quiser um desempenho muito elevado do Hyperdisk, pode ter de aumentar o número de núcleos da VM. Se as suas cargas de trabalho mais exigentes precisarem de um desempenho do disco superior ao que um único disco Hyperdisk Balanced pode oferecer, pode usar um dos seguintes métodos para combinar vários discos Hyperdisk Balanced:

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

À medida que dimensiona as suas bases de dados MySQL, pode aumentar dinamicamente a capacidade e o desempenho dos seus discos sem tempo de inatividade. Isto ajuda o desempenho das cargas de trabalho de processamento analítico online (OLAP) que fazem junções complexas grandes que não cabem na RAM e transbordam para o disco. Em casos raros, as cargas de trabalho do MySQL que requerem uma latência de armazenamento extremamente baixa e podem tolerar a perda de dados podem armazenar o respetivo conjunto de dados completo no SSD local. Também pode usar as seguintes soluções híbridas para melhorar a latência de leitura e limitar as reduções na durabilidade:

  • Duplique o seu conjunto de dados entre um Hyperdisk e um SSD local.
  • Use um gestor de volumes para configurar o SSD local como uma cache para dados armazenados num Hyperdisk subjacente.

Tire partido das funcionalidades adicionais do Hyperdisk

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

Para mais informações sobre a configuração destas funcionalidades com o MySQL para o Compute Engine, consulte a secção de alta disponibilidade que se segue nesta página.

SSDs locais

Algumas famílias de máquinas do Compute Engine permitem-lhe usar SSDs locais em vez do Hyperdisk. Não se trata de armazenamento duradouro, mas as cargas de trabalho do MySQL usam-nos frequentemente para armazenar espaços de tabelas temporários.

Para informações sobre a utilização de SSDs locais para dimensionar bases de dados MySQL, consulte a secção Redimensionamento dinâmico de discos, que se segue nesta página.

Funcionalidades adicionais do Compute Engine

Pode usar as seguintes funcionalidades do Compute Engine para ajudar a otimizar a sua implementação do MySQL.

Cloud Monitoring

Para monitorizar o desempenho e a utilização dos serviços de infraestrutura da sua VM, use a Google Cloud consola. Na página Instâncias de VM, no separador Observabilidade, pode monitorizar métricas relacionadas com o desempenho, como a utilização da CPU e da memória, a largura de banda da rede e o desempenho aprovisionado das suas instâncias. Da mesma forma, na página Discos, no separador Observabilidade, pode monitorizar o débito e os IOPS dos seus volumes de disco.

Para personalizar as métricas de desempenho que vê, use o Cloud Monitoring para criar consultas. Pode selecionar as métricas de desempenho específicas que quer ver para os 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 seu sistema operativo

  • Use um sistema de ficheiros adequado. A Google foca-se na otimização para os sistemas de ficheiros ext4 e XFS do Linux. No entanto, a maioria dos sistemas de ficheiros é adequada para utilização com o MySQL.
  • Desative as páginas enormes transparentes (THP) na configuração do sistema operativo base. Para ver os passos para desativar o THP, consulte a documentação do THP.
  • Se estiver a usar o Linux, use os flags relatime e lazytime para a configuração de montagem do sistema de ficheiros. Isto reduz os custos gerais de desempenho associados à atualização dos valores atime, mtime e ctime nos ficheiros quando são lidos, modificados ou têm os respetivos metadados alterados.

Práticas recomendadas para configurar o MySQL

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

  • Use uma versão recente do MySQL. A Google foca-se na otimização para o MySQL versão 8.0 e versões posteriores.

  • Aumente o tamanho do conjunto de memória intermédia. O MySQL usa o respetivo buffer pool para melhorar o desempenho de leitura ao colocar dados em cache na RAM, o que reduz os acessos ao disco. Por predefinição, o tamanho do conjunto de buffers do MySQL é de 128 MiB, o que é demasiado pequeno para a maioria dos exemplos de utilização práticos. Recomendamos que aumente o tamanho do innodb_buffer_pool_size para que seja superior ao tamanho do conjunto de trabalho ao qual a sua aplicação acede na base de dados. Normalmente, isto consiste nos seguintes passos:

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

  • Ative o buffer de gravação dupla. O MySQL tem um buffer de escrita dupla que ajuda a proteger contra escritas incompletas, um modo de falha em que uma escrita que abrange vários blocos no disco pode apenas ser parcialmente confirmada se ocorrer uma falha de hardware ou de energia no meio da escrita. Para beneficiar desta proteção, ative a opção innodb_doublewrite.

  • Defina o valor de innodb_flush_log_at_trx_commit para 1. Isto garante que as transações de escrita são duradouras no disco quando são confirmadas.

  • Para reduzir a sobrecarga de desempenho, especifique um valor para innodb_flush_method. Para a versão 8.0.14 e posteriores do MySQL, defina o valor de innodb_flush_method como O_DIRECT_NO_FSYNC, que é o ideal, mas só está presente nestas 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 da base de dados principal como 1. O MySQL usa o respetivo registo binário para comunicar alterações da base de dados principal à base de dados secundária. Deste modo, garante que os registos binários são 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íveis entre as bases de dados.

  • Quando usar o MySQL em famílias de máquinas da série C, ative a opção innodb_numa_interleave. Isto garante que o buffer pool do MySQL pode tirar partido das políticas de acesso à memória não uniforme (NUMA).

Quando desativar o buffer de gravação dupla

O buffer de escrita dupla do MySQL, que protege contra escritas incompletas, tem uma sobrecarga de desempenho de até 25% para transações de escrita do MySQL, o que pode afetar potencialmente a latência das transações. O Google Cloud Hyperdisk também oferece proteção contra gravação danificada. Por isso, se estiver a usar o MySQL para escrever diretamente num sistema de ficheiros ext4 executado no Hyperdisk, pode desativar em segurança o buffer de gravação dupla.

No entanto, para que a proteção contra escrita interrompida do Hyperdisk seja eficaz, tem de configurar o sistema de ficheiros e outras camadas de software intermédias entre a base de dados e o disco para evitar a introdução de escritas interrompidas acima da camada de disco. A lista seguinte apresenta exemplos de configurações que podem introduzir escritas incompletas acima da camada do Hyperdisk:

  • Executar a sua instância do MySQL em contentores, como o Google Kubernetes Engine ou o Kubernetes alojado por si.
  • Armazenar os seus ficheiros MySQL num sistema de ficheiros XFS, que não suporta tamanhos de blocos suficientemente grandes na maioria das configurações do kernel do Linux.
  • Armazenar os seus ficheiros MySQL numa configuração de matriz redundante de discos independentes (RAID) que cause a divisão em faixas de disco, como mdadm para Linux ou Espaços de armazenamento e Espaços de armazenamento direto para Windows.
  • Armazenar os seus ficheiros MySQL num gestor de volumes, como o Logical Volume Manager (LVM) para Linux ou os Espaços de armazenamento e os Espaços de armazenamento direto para Windows.

  • Armazenar os seus ficheiros MySQL no Hyperdisk com um SSD local configurado como uma cache, como usar lvmcache, dm-cache ou bcache para Linux ou Storage Spaces para Windows.

  • Executar a sua instância do MySQL numa VM através da virtualização aninhada.

Embora possa configurar as configurações anteriores para que não introduzam gravações incompletas, não recomendamos que desative o buffer de gravação dupla quando as usar, 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, conclua os seguintes passos:

  1. No sistema de ficheiros ext4, tem de ativar a funcionalidade bigalloc e configurar o tamanho do cluster do sistema de ficheiros para 16 KiB ou um múltiplo de 2 superior a 16 KiB. Isto garante que as escritas do MySQL não são divididas em IOs separados pelo sistema de ficheiros antes de serem emitidas para o Hyperdisk. Se não aumentar o limite ou usar qualquer valor inferior a 16 KiB, não se protege contra gravações incompletas. Como exemplo com um tamanho de cluster de 16 KiB, isto é configurado no momento da criação do sistema de ficheiros:

    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 (consoante a sua versão do MySQL, conforme descrito acima).

Configure a alta disponibilidade (HA) e uma solução de cópia de segurança

Recomendamos vivamente que proteja todas as suas cargas de trabalho críticas do MySQL configurando soluções de alta disponibilidade (HA) e de cópia de segurança para as mesmas. Para a HA e a cópia de segurança, os seguintes fatores são mais importantes:

Geralmente, as soluções de HA destinam-se a RTO e RPO quase nulos, mas só protegem contra falhas de infraestrutura. As soluções de cópia de segurança destinam-se a janelas de RTO e RPO mais longas, mas oferecem cobertura para um conjunto maior de cenários de falha, como os seguintes:

  • Eliminação acidental de dados
  • Ataques de ransomware
  • Desastres naturais

Configure a alta disponibilidade (HA)

As funcionalidades de HA usam a redundância de armazenamento e computação para garantir que a sua base de dados MySQL tem um tempo de inatividade reduzido em caso de falha ou indisponibilidade do anfitrião, permitindo que as aplicações cliente acedam aos respetivos dados mesmo quando uma instância ou uma zona está indisponível.

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

  • Modo assíncrono. No modo assíncrono, o nó principal confirma as transações de escrita assim que são comprometidas localmente. Por isso, se houver uma indisponibilidade no nó principal, pode perder uma pequena quantidade de dados escritos recentemente durante a comutação por falha, uma vez que o RPO é próximo de zero, mas não é efetivamente zero.
  • Modo semissíncrono. No modo semissíncrono, o nó principal aguarda a confirmação da transação até que um número configurável de réplicas tenha confirmado a receção da transação. Isto aumenta significativamente a probabilidade de não ocorrer perda de dados durante uma comutação por falha não planeada, uma vez que o RPO é efetivamente zero.

Para ambos os modos, o RTO é determinado pela rapidez com que as verificações de estado fazem o seguinte:

  1. Identifique uma instância com falha.
  2. Acione a comutação por falha.
  3. Notificar os clientes de que a instância de comutação por falha é agora a principal através do sistema de nomes de domínio (DNS) ou de outra forma de identificar o servidor de base de dados.

Em qualquer modo de replicação, tem de ter uma instância de comutação por falha para replicar. Pode 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 onde a instância principal está localizada
  • Uma região diferente da região principal

Para manter a elevada disponibilidade, mesmo durante interrupções zonais, recomendamos a seguinte configuração:

  • Localize as suas instâncias principal e de alternativa em zonas diferentes, quer estejam ou não na mesma região.
  • Use a replicação assíncrona. Isto deve-se ao facto de, se estiver a usar a replicação semissíncrona, a localização das instâncias principal e de alternativa em zonas separadas poder causar uma latência elevada para as confirmações de transações de escrita.
  • Se precisar de um RPO zero, use o Hyperdisk Balanced de alta disponibilidade, que lhe permite replicar um disco de forma síncrona em duas zonas na mesma região. Para mais detalhes, consulte o guia da Google sobre como fornecer serviços de HA através da elevada disponibilidade do Hyperdisk. Quando configura a elevada disponibilidade do Hyperdisk Balanced, recomendamos a integração com grupos de instâncias geridas com estado para diagnosticar problemas de estado das instâncias e automatizar ações de recuperação.

Configure um plano de resiliência de dados e cópia de segurança

Os planos de cópia de segurança e resiliência de dados ajudam a evitar a perda de dados durante falhas, como a eliminação acidental de dados, ataques de ransomware e desastres naturais. Também pode usá-los como armazenamento a frio para requisitos de conformidade e auditoria. Para o MySQL, existem muitas metodologias de cópia de segurança à escolha, algumas das quais atuam ao nível da base de dados e outras ao nível do volume de armazenamento. À medida que seleciona uma metodologia, deve considerar principalmente os requisitos de RTO e RPO.

Faça uma cópia de segurança ao nível da base de dados

Para cópias de segurança ao nível da base de dados, considere usar as seguintes opções fornecidas pelo MySQL:

  • Cópias de segurança incrementais baseadas no registo binário,que criam descargas de dados lógicas. Estes incluem o seguinte:
  • Ferramentas que gerem o processo de cópia de segurança por si,como o MySQL Enterprise Backup.

Para mais informações sobre as opções de cópia de segurança ao nível da base de dados do MySQL, consulte o artigo Cópia de segurança e recuperação na documentação do MySQL.

Para qualquer uma destas opções, tem de ter um sistema de armazenamento secundário para copiar os dados de cópia de segurança. Recomendamos as seguintes ferramentas:

Use o Hyperdisk para criar instantâneos e clonar ao nível do armazenamento

Para cópias de segurança ao nível do armazenamento, recomendamos a utilização de produtos Hyperdisk para criar instantâneos, clonar e, de outra forma, capturar uma vista num determinado momento da sua base de dados MySQL. O RPO desta abordagem depende da frequência com que tira instantâneos da base de dados, e o RTO depende da solução específica que usa.

Se a recuperação rápida for importante para si e só precisar de cobertura de cópia de segurança numa zona, recomendamos que use os instantâneos do Hyperdisk. Os instantâneos instantâneos capturam dados num ponto específico no tempo de forma incremental e podem restaurar rapidamente os dados para um novo volume do Hyperdisk através da clonagem de discos, oferecendo um RTO de minutos. Permitem-lhe recuperar dados quando o conteúdo de um disco foi substituído, eliminado ou danificado, e estão disponíveis localmente na mesma zona ou região que o disco de origem. Para mais informações, consulte o artigo Acerca das capturas instantâneas

Para cenários de recuperação de desastres, nos quais os dados têm de ser armazenados com uma redundância superior à do disco original e numa localização separada para garantir que um único desastre não afeta todas as réplicas dos dados, recomendamos que use as cópias de segurança de arquivo e as imagens instantâneas de disco padrão do Hyperdisk. As cópias instantâneas de disco padrão e de arquivo criam uma cópia dos dados no disco num determinado momento e armazenam-na com elevada redundância num formato imutável. Quando cria vários instantâneos de um disco, como com um agendamento de instantâneos, o Hyperdisk armazena apenas alterações incrementais. As cópias instantâneas de arquivo e de disco padrão são adequadas se puder tolerar um RTO mais elevado, porque a cópia de dados do armazenamento de cópias instantâneas para o armazenamento de VMs pode significar que demoram mais tempo a restaurar. Para mais informações, consulte o artigo Crie instantâneos de discos padrão e de arquivo.

As capturas instantâneas do Hyperdisk e as respetivas capturas instantâneas de arquivo e padrão são consistentes em caso de falha num único disco. Isto significa que, quando faz o restauro a partir de uma captura instantânea, a sua base de dados MySQL tem de executar os passos de recuperação do InnoDB normais para repor os respetivos registos e ficheiros de dados num estado consistente. Dependendo da configuração do registo de refazer do InnoDB, isto pode aumentar o RTO. Os seguintes padrões podem complicar ainda mais os seus esforços para criar uma imagem instantânea da base de dados consistente:

  • Os ficheiros da base de dados do MySQL estão distribuídos por vários volumes.
  • Está a usar utilitários RAID de software Linux, como mdadm.
  • Separou as localizações de armazenamento configuradas do MySQL em sistemas de ficheiros em discos diferentes.

Para criar um instantâneo que não requer recuperação após um restauro do instantâneo, conclua os seguintes passos:

  1. Bloqueia temporariamente o acesso de escrita à base de dados do MySQL.
  2. Libere todas as memórias intermédias em curso para o disco através dos comandos LOCK INSTANCE FOR BACKUP e FLUSH TABLES WITH READ LOCK.
  3. Inicie as operações de instantâneo.

  4. Para cenários com vários discos, depois de esvaziar ao nível do MySQL, execute os comandos sync e fsfreeze no servidor para esvaziar todas as escritas em curso para o disco e pausar as novas escritas recebidas ao nível do sistema de ficheiros.

Depois de capturar a imagem instantânea inicial da base de dados, não precisa de continuar a bloquear o disco, porque o Hyperdisk captura rapidamente a vista num determinado momento e, em seguida, pode processar de forma assíncrona todos os passos de cópia de armazenamento subsequentes. Se precisar destes passos para a consistência de instantâneos e quiser remover este impacto de escrita na base de dados principal, também pode executar uma cópia de segurança numa réplica da base de dados em vez da base de dados principal.

O que se segue?