Alta disponibilidade MySQL em produção: cluster InnoDB, replicação de grupo e operadores Kubernetes

Executar o MySQL em produção é um território familiar para a maioria das equipes de engenharia. Executá-lo com alta disponibilidade genuína – onde uma falha de nó, uma partição de rede ou uma zona de disponibilidade inteira ficando escura não resulta em tempo de inatividade ou perda de dados – requer uma arquitetura deliberada. Este guia percorre cada camada dessa arquitetura: desde as primitivas de replicação dentro do próprio MySQL, passando pelos operadores Kubernetes que automatizam o gerenciamento do ciclo de vida, passando pelas opções gerenciadas e autogerenciadas em todos os principais provedores de nuvem, até clusters bare metal k3s gerenciados pelo Rancher.

Ao final deste artigo você terá um modelo mental completo para escolher e operar o MySQL HA em produção, juntamente com exemplos concretos de configuração que você pode adaptar ao seu próprio ambiente.

MySQL InnoDB

InnoDB Cluster é a solução integrada de alta disponibilidade da Oracle para MySQL. Ele combina três componentes: Replicação de Grupo MySQL para sincronização de dados, Shell MySQL para administração de cluster e Roteador MySQL para roteamento de conexão transparente e failover automático. Juntos, eles formam um cluster de autocorreção que pode tolerar falhas de nós sem intervenção manual.

A arquitetura é elegante em sua simplicidade. Os aplicativos se conectam ao roteador MySQL, que mantém o conhecimento da topologia do cluster consultando o esquema de metadados do cluster InnoDB. Quando o primário falha, a replicação de grupo elege um novo primário dentre os secundários restantes, e o roteador MySQL redireciona automaticamente o tráfego de gravação para o novo primário, normalmente em segundos. O tráfego de leitura pode ser distribuído por todos os secundários para escalonamento de leitura horizontal.

MySQL é a base do cluster InnoDB. Ele usa um protocolo de consenso baseado em Paxos para garantir que cada transação confirmada no primário seja replicada para a maioria dos nós antes de ser reconhecida. Isso fornece replicação síncrona virtual— uma garantia de que os dados confirmados existem em pelo menos a maioria dos membros do cluster no momento da confirmação.

opera em dois modos:

• Modo Primário Único— Um nó aceita gravações (o primário); todos os outros são secundários somente leitura. Este é o modo recomendado e padrão. Ele evita totalmente conflitos de gravação porque apenas um nó pode gerar transações.
• Modo Multiprimário— Todos os nós aceitam gravações simultaneamente. Isso oferece maior rendimento de gravação para cargas de trabalho que particionam de forma limpa em diferentes tabelas ou keyspaces, mas introduz a possibilidade de conflitos de certificação quando transações simultâneas modificam as mesmas linhas. As transações conflitantes são revertidas em um nó. Use multiprimário somente quando seu aplicativo for projetado para lidar com falhas de certificação e lógica de nova tentativa.

Configurando Cluster InnoDB com MySQL Shell

MySQL Shell fornece o AdminAPI, um conjunto de funções que automatiza todo o ciclo de vida do cluster. Aqui está a sequência completa de configuração para um cluster de 3 nós.

# Step 1: Prepare each MySQL instance (run on all 3 nodes)
# Ensure my.cnf has required settings
[mysqld]
server-id=1                          # unique per node: 1, 2, 3
gtid_mode=ON
enforce_gtid_consistency=ON
binlog_checksum=NONE
binlog_transaction_dependency_tracking=WRITESET
transaction_write_set_extraction=XXHASH64
loose-group_replication_start_on_boot=OFF
plugin_load_add='group_replication.so'
plugin_load_add='mysql_clone.so'
report_host='mysql-node-1'           # unique per node

# Step 2: Use MySQL Shell to configure and create the cluster
mysqlsh -- dba configure-instance root@mysql-node-1:3306 --clusterAdmin=gradmin --clusterAdminPassword='SecurePass123!'
mysqlsh -- dba configure-instance root@mysql-node-2:3306 --clusterAdmin=gradmin --clusterAdminPassword='SecurePass123!'
mysqlsh -- dba configure-instance root@mysql-node-3:3306 --clusterAdmin=gradmin --clusterAdminPassword='SecurePass123!'

# Step 3: Connect to the first node and create the cluster
mysqlsh gradmin@mysql-node-1:3306
# Inside MySQL Shell:
var cluster = dba.createCluster('productionCluster', {
    memberWeight: 90,
    exitStateAction: 'ABORT_SERVER',
    consistency: 'BEFORE_ON_PRIMARY_FAILOVER',
    expelTimeout: 10
})

# Step 4: Add remaining nodes
cluster.addInstance('gradmin@mysql-node-2:3306', {recoveryMethod: 'clone'})
cluster.addInstance('gradmin@mysql-node-3:3306', {recoveryMethod: 'clone'})

# Step 5: Verify cluster status
cluster.status()

A opçãorecoveryMethod: 'clone'usa o plug-in Clone MySQL para executar uma cópia completa dos dados do primário para o membro associado, o que é muito mais rápido do que a recuperação incremental de logs binários para grandes conjuntos de dados.

MySQL

MySQL é inicializado no cluster e gera automaticamente seu arquivo de configuração.

# Bootstrap MySQL Router against the cluster
mysqlrouter --bootstrap gradmin@mysql-node-1:3306 \
  --directory /opt/mysqlrouter \
  --conf-use-sockets \
  --user=mysqlrouter \
  --name='production-router'

# Start MySQL Router
/opt/mysqlrouter/start.sh

# Default ports after bootstrap:
# 6446 — R/W (routes to primary)
# 6447 — R/O (round-robin across secondaries)
# 6448 — R/W (X Protocol)
# 6449 — R/O (X Protocol)

se conectam à porta R/W do roteador para gravações e à porta R/O para réplicas de leitura. Quando o primário falha, o roteador detecta a mudança de topologia e redireciona em segundos.

Para recuperação de desastres e leituras de baixa latência em regiões geográficas, o MySQL pode ser implantado em diversas regiões. O InnoDB ClusterSet estende o InnoDB Cluster para suportar replicação assíncrona entre um cluster primário e um ou mais clusters de réplica em diferentes regiões.

InnoDB ClusterSet opera com um cluster primário que lida com todas as gravações e um ou mais clusters de réplica que recebem alterações de forma assíncrona. Em um cenário de desastre, um cluster de réplica pode ser promovido a primário por meio do MySQL Shell.

# Create a ClusterSet from an existing InnoDB Cluster
mysqlsh gradmin@mysql-node-1:3306
var cluster = dba.getCluster()
var cs = cluster.createClusterSet('globalSet')

# Create a replica cluster in eu-west region
cs.createReplicaCluster('gradmin@mysql-eu-node-1:3306', 'euWestCluster', {
    recoveryMethod: 'clone'
})
var euCluster = cs.getCluster('euWestCluster')
euCluster.addInstance('gradmin@mysql-eu-node-2:3306', {recoveryMethod: 'clone'})
euCluster.addInstance('gradmin@mysql-eu-node-3:3306', {recoveryMethod: 'clone'})

# Emergency failover (when primary cluster is unreachable)
cs.forcePrimaryCluster('euWestCluster')

MySQL em Kubernetes — Padrão do Operador

A execução do MySQL no Kubernetes requer a solução de vários desafios que não se aplicam a cargas de trabalho sem estado: identidades de rede estáveis, armazenamento persistente, inicialização e desligamento ordenados e verificações de integridade com reconhecimento de cluster. Os operadores do Kubernetes codificam esse conhecimento operacional específico do domínio em um controlador que monitora os recursos personalizados e reconcilia o estado real do MySQL com o estado desejado declarado no YAML.

MySQL para Kubernetes (Oracle)

O Operador MySQL da Oracle para Kubernetes implanta e gerencia instâncias de cluster InnoDB nativamente no Kubernetes. Ele cria StatefulSets para pods de servidor MySQL, implantações para roteador MySQL e lida com failover automatizado, dimensionamento, backup e alterações de configuração.

# Install the MySQL Operator via Helm
helm repo add mysql-operator https://mysql.github.io/mysql-operator/
helm repo update

helm install mysql-operator mysql-operator/mysql-operator \
  --namespace mysql-operator \
  --create-namespace \
  --set image.pullPolicy=IfNotPresent

Quando o operador estiver em execução, implante um cluster InnoDB criando um recurso customizado.

apiVersion: v1
kind: Secret
metadata:
  name: mysql-root-credentials
  namespace: production
stringData:
  rootUser: root
  rootHost: '%'
  rootPassword: 'ProductionSecurePass123!'
---
apiVersion: mysql.oracle.com/v2
kind: InnoDBCluster
metadata:
  name: production-mysql
  namespace: production
spec:
  secretName: mysql-root-credentials
  instances: 3
  tlsUseSelfSigned: true
  router:
    instances: 2
  datadirVolumeClaimTemplate:
    accessModes:
      - ReadWriteOnce
    resources:
      requests:
        storage: 100Gi
    storageClassName: gp3-encrypted
  mycnf: |
    [mysqld]
    innodb_buffer_pool_size=4G
    innodb_log_file_size=1G
    innodb_flush_log_at_trx_commit=1
    sync_binlog=1
    max_connections=500
    innodb_io_capacity=2000
    innodb_io_capacity_max=4000
    innodb_read_io_threads=8
    innodb_write_io_threads=8
    performance_schema=ON
    slow_query_log=ON
    long_query_time=1
  podSpec:
    containers:
      - name: mysql
        resources:
          requests:
            cpu: "2"
            memory: 8Gi
          limits:
            cpu: "4"
            memory: 16Gi
    affinity:
      podAntiAffinity:
        requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
                - key: component
                  operator: In
                  values: [mysqld]
            topologyKey: topology.kubernetes.io/zone

A regra de antiafinidade do pod garante que os pods MySQL sejam espalhados pelas zonas de disponibilidade, fornecendo tolerância a falhas no nível da zona. O blocomycnfpermite injetar configuração MySQL ajustada para produção diretamente por meio do CR.

para MySQL (PXC)

Percona Operator para MySQL implanta Percona XtraDB Cluster (PXC), uma solução de replicação síncrona multiprimária baseada em Galera. O PXC difere do InnoDB Cluster porque cada nó pode aceitar gravações (verdadeiro multiprimário) e a replicação é síncrona no nível de certificação usando o wsrep API.

# Install Percona Operator
helm repo add percona https://percona.github.io/percona-helm-charts/
helm repo update

helm install pxc-operator percona/pxc-operator \
  --namespace pxc \
  --create-namespace

# Percona XtraDB Cluster Custom Resource
apiVersion: pxc.percona.com/v1
kind: PerconaXtraDBCluster
metadata:
  name: production-pxc
  namespace: pxc
spec:
  crVersion: '1.14.0'
  secretsName: pxc-secrets
  pxc:
    size: 3
    image: percona/percona-xtradb-cluster:8.0.35
    resources:
      requests:
        memory: 8Gi
        cpu: "2"
      limits:
        memory: 16Gi
        cpu: "4"
    volumeSpec:
      persistentVolumeClaim:
        storageClassName: gp3-encrypted
        accessModes: [ReadWriteOnce]
        resources:
          requests:
            storage: 200Gi
    affinity:
      antiAffinityTopologyKey: topology.kubernetes.io/zone
    configuration: |
      [mysqld]
      innodb_buffer_pool_size=4G
      innodb_flush_log_at_trx_commit=1
      wsrep_provider_options="gcache.size=2G; gcs.fc_limit=256"
      wsrep_slave_threads=8
      wsrep_certify_nonPK=1
      wsrep_trx_fragment_size=10M
      max_connections=500
  haproxy:
    enabled: true
    size: 3
    image: percona/haproxy:2.8.5
    resources:
      requests:
        memory: 1Gi
        cpu: 500m
  proxysql:
    enabled: false
  backup:
    image: percona/percona-xtradb-cluster-operator:1.14.0-pxc8.0-backup-pxb8.0.35
    storages:
      s3-backup:
        type: s3
        verifyTLS: true
        s3:
          bucket: production-mysql-backups
          region: us-east-1
          credentialsSecret: aws-s3-credentials
    schedule:
      - name: daily-full
        schedule: "0 3 * * *"
        keep: 7
        storageName: s3-backup
      - name: hourly-incremental
        schedule: "0 * * * *"
        keep: 24
        storageName: s3-backup

O Operador Percona lida com backups automatizados para S3, recuperação pontual, atualizações contínuas e ProxySQL ou HAProxy para roteamento de conexão. A replicação baseada em Galera em PXC fornece gravações multiprimárias síncronas verdadeiras – é garantido que cada transação confirmada exista em todos os nós.

: Roteador MySQL vs ProxySQL

Tanto o roteador MySQL quanto o ProxySQL servem como proxies de banco de dados, mas têm qualidades diferentes.

Roteador MySQLfoi desenvolvido especificamente para InnoDB Cluster. Ele lê os metadados do cluster, rastreia alterações de topologia e roteia conexões para o primário ou secundário correto. Sua configuração é mínima e integra-se perfeitamente ao ecossistema MySQL. A desvantagem é o roteamento limitado no nível da consulta – ele opera no nível da conexão, não no nível da consulta.

ProxySQLé um proxy MySQL de uso geral com recursos avançados: divisão de leitura/gravação em nível de consulta, cache de consulta, multiplexação de conexão, reescrita de consulta e regras de roteamento sofisticadas. Ele é excelente em ambientes onde você precisa de controle refinado sobre como as consultas são distribuídas.

# ProxySQL configuration for read/write splitting
# proxysql.cnf

mysql_servers:
(
    { hostgroup_id=10, hostname="mysql-primary", port=3306, max_connections=200, weight=1000 },
    { hostgroup_id=20, hostname="mysql-secondary-1", port=3306, max_connections=200, weight=500 },
    { hostgroup_id=20, hostname="mysql-secondary-2", port=3306, max_connections=200, weight=500 }
)

mysql_query_rules:
(
    { rule_id=1, active=1, match_digest="^SELECT .* FOR UPDATE$", destination_hostgroup=10, apply=1 },
    { rule_id=2, active=1, match_digest="^SELECT", destination_hostgroup=20, apply=1 },
    { rule_id=3, active=1, match_digest=".*", destination_hostgroup=10, apply=1 }
)

mysql_replication_hostgroups:
(
    { writer_hostgroup=10, reader_hostgroup=20, comment="InnoDB Cluster" }
)

Em ambientes Kubernetes, o ProxySQL pode ser executado como um contêiner secundário em seus pods de aplicativos ou como uma implantação dedicada. Executá-lo como sidecar elimina saltos de rede, mas aumenta o uso de recursos do pod; uma implantação dedicada é mais fácil de gerenciar em escala.

:

AWS: RDS Multi-AZ vs Aurora vs autogerenciado em EKS

Amazon RDS Multi-AZfornece failover automático entre uma instância primária e uma instância em espera em diferentes zonas de disponibilidade. O failover normalmente leva de 60 a 120 segundos. Ele usa replicação física síncrona para o modo de espera. Réplicas de leitura podem ser adicionadas para escalonamento de leitura, mas usam replicação assíncrona. O RDS lida com backups, aplicação de patches e monitoramento, mas limita seu controle sobre a configuração da MySQL e a escolha de versão.

Amazon Aurora MySQLé uma reescrita nativa da nuvem do mecanismo de armazenamento MySQL. Ele separa a computação do armazenamento – a camada de armazenamento é um sistema distribuído e tolerante a falhas que replica dados de seis maneiras em três AZs. O Aurora oferece failover em menos de 10 segundos, até 15 réplicas de leitura com atraso mínimo de replicação e escalabilidade automática de armazenamento para até 128 TiB. O Aurora Serverless v2 adiciona escalabilidade automática de computação para cargas de trabalho imprevisíveis. A compensação é o custo (o Aurora é 20–40% mais caro que o RDS) e a compatibilidade reduzida com determinados recursos do MySQL.

autogerenciado no EKSoferece controle total sobre a versão, configuração e topologia de replicação do MySQL. Use-o quando precisar de recursos específicos do MySQL não disponíveis em serviços gerenciados, quando precisar de portabilidade multinuvem ou quando a otimização de custos em escala justificar a sobrecarga operacional.

# EKS StorageClass for MySQL with gp3 volumes
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: gp3-encrypted
provisioner: ebs.csi.aws.com
parameters:
  type: gp3
  iops: "6000"
  throughput: "250"
  encrypted: "true"
  fsType: ext4
volumeBindingMode: WaitForFirstConsumer
reclaimPolicy: Retain
allowVolumeExpansion: true

Azure: Servidor flexível vs autogerenciado em AKS

Banco de dados Azure para servidor flexível MySQL Ooferece HA com redundância de zona com failover automático, réplicas de leitura na mesma região e armazenamento de até 16 TiB. Ele suporta janelas de manutenção configuráveis, a capacidade de parar/iniciar instâncias (útil para economia de custos de desenvolvimento/teste) e integração com o Azure Private Link para isolamento de rede. A camada Business Critical oferece o melhor desempenho com armazenamento SSD local.

autogerenciado no AKSusa discos gerenciados Azure (SSD Premium v2 recomendado para cargas de trabalho de banco de dados) com o operador MySQL ou operador Percona. O AKS fornece suporte a zonas de disponibilidade e o CNI Azure para integração VNET em nível de pod.

# AKS StorageClass for MySQL
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: premium-ssd-zrs
provisioner: disk.csi.azure.com
parameters:
  skuName: Premium_ZRS
  cachingMode: None
  DiskIOPSReadWrite: "5000"
  DiskMBpsReadWrite: "200"
volumeBindingMode: WaitForFirstConsumer
reclaimPolicy: Retain
allowVolumeExpansion: true

Google Cloud: Cloud SQL versus autogerenciado no GKE

Google Cloud SQL para MySQLoferece instâncias regionais com failover automático entre zonas, réplicas de leitura (incluindo entre regiões) e backups automatizados com recuperação pontual. O Cloud SQL oferece o mais alto nível de conveniência gerenciada com integração ao IAM, VPC e ecossistema de monitoramento do Google. A camada Enterprise Plus adiciona manutenção com tempo de inatividade quase zero e cache de dados para melhorar o desempenho de leitura.

autogerenciado no GKEusa disco permanente SSD ou hiperdisco para armazenamento. O GKE Autopilot simplifica o gerenciamento de nós e pode executar o MySQL Operator com sobrecarga operacional mínima.

# GKE StorageClass for MySQL
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: ssd-regional
provisioner: pd.csi.storage.gke.io
parameters:
  type: pd-ssd
  replication-type: regional-pd
volumeBindingMode: WaitForFirstConsumer
reclaimPolicy: Retain
allowVolumeExpansion: true

Bare Metal: k3s + Rancher + Longhorn

Nem toda carga de trabalho pertence à nuvem pública. Para requisitos de soberania de dados, conformidade, otimização de custos ou latência, os clusters bare metal Kubernetes que executam k3s com gerenciamento Rancher e armazenamento Longhorn fornecem uma plataforma de nível de produção para MySQL HA.

k3s

k3s é uma distribuição Kubernetes leve e certificada, ideal para edge e bare metal. Ele agrupa todos os componentes do plano de controle em um único binário e usa SQLite ou etcd incorporado para armazenamento de estado.

# Install k3s server (first control-plane node)
curl -sfL https://get.k3s.io | sh -s - server \
  --cluster-init \
  --tls-san 10.10.0.10 \
  --disable traefik \
  --disable servicelb \
  --write-kubeconfig-mode 644

# Join additional server nodes
curl -sfL https://get.k3s.io | K3S_TOKEN=$(cat /var/lib/rancher/k3s/server/node-token) sh -s - server \
  --server https://10.10.0.10:6443 \
  --tls-san 10.10.0.10

# Join worker nodes
curl -sfL https://get.k3s.io | K3S_URL=https://10.10.0.10:6443 \
  K3S_TOKEN=$(cat /var/lib/rancher/k3s/server/node-token) sh -s -

para MySQL

Longhorn é um sistema de armazenamento em bloco distribuído nativo da nuvem desenvolvido para Kubernetes. Ele replica dados entre nós, fornece snapshots e backups e integra-se nativamente ao driver Kubernetes CSI. Para o MySQL, o Longhorn fornece a camada de armazenamento persistente e replicada que os provedores de nuvem gerenciam com suas ofertas de disco gerenciado.

# Install Longhorn
helm repo add longhorn https://charts.longhorn.io
helm repo update

helm install longhorn longhorn/longhorn \
  --namespace longhorn-system \
  --create-namespace \
  --set defaultSettings.defaultReplicaCount=3 \
  --set defaultSettings.storageMinimalAvailablePercentage=15 \
  --set defaultSettings.guaranteedInstanceManagerCPU=12

# StorageClass for MySQL on Longhorn
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: longhorn-mysql
provisioner: driver.longhorn.io
parameters:
  numberOfReplicas: "3"
  staleReplicaTimeout: "2880"
  dataLocality: best-effort
  diskSelector: ssd
  fsType: ext4
reclaimPolicy: Retain
volumeBindingMode: Immediate
allowVolumeExpansion: true

MetalLB para balanceamento de carga

Em bare metal, não há balanceador de carga em nuvem. MetalLB preenche essa lacuna atribuindo endereços IP externos aos serviços Kubernetes do tipo LoadBalancer usando o modo Camada 2 (ARP) ou BGP.

# MetalLB IP Address Pool and L2 Advertisement
apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: mysql-pool
  namespace: metallb-system
spec:
  addresses:
    - 10.10.0.100-10.10.0.110
---
apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:
  name: mysql-l2
  namespace: metallb-system
spec:
  ipAddressPools:
    - mysql-pool

Um cluster de alta disponibilidade protege contra falhas de nós. Os backups protegem contra corrupção de dados, exclusões acidentais, bugs de aplicativos e cenários de recuperação de desastres em que todo o cluster é perdido. Você precisa de ambos.

com mysqldump

mysqldumpproduz backups no formato SQL que são portáteis e legíveis por humanos. Para bancos de dados com menos de 50 GB, é a opção mais simples. Para conjuntos de dados maiores, o tempo de bloqueio e exportação torna impraticável o uso em produção durante o horário comercial.

# Full logical backup with consistent snapshot
mysqldump --all-databases \
  --single-transaction \
  --routines \
  --triggers \
  --events \
  --set-gtid-purged=ON \
  --result-file=/backups/full-$(date +%Y%m%d-%H%M%S).sql

# Compressed backup piped to S3
mysqldump --all-databases --single-transaction | \
  gzip | aws s3 cp - s3://mysql-backups/full-$(date +%Y%m%d).sql.gz

com Percona XtraBackup

Percona XtraBackup executa backups físicos dinâmicos e sem bloqueio de dados InnoDB. Ele copia os arquivos de dados do InnoDB enquanto rastreia o redo log e, em seguida, aplica o redo log durante a fase de preparação para produzir um backup consistente. É dramaticamente mais rápido que o mysqldump para grandes conjuntos de dados e suporta backups incrementais.

# Full physical backup
xtrabackup --backup \
  --target-dir=/backups/full \
  --user=backup_user \
  --password=SecureBackupPass \
  --parallel=4 \
  --compress \
  --compress-threads=4

# Incremental backup based on previous full
xtrabackup --backup \
  --target-dir=/backups/incr-$(date +%H) \
  --incremental-basedir=/backups/full \
  --user=backup_user \
  --password=SecureBackupPass

# Prepare (apply redo log) and restore
xtrabackup --prepare --target-dir=/backups/full
xtrabackup --prepare --target-dir=/backups/full \
  --incremental-dir=/backups/incr-01

# Copy back to data directory
xtrabackup --copy-back --target-dir=/backups/full --datadir=/var/lib/mysql
chown -R mysql:mysql /var/lib/mysql

(binlog) Recuperação pontual

registram todas as transações de modificação de dados. Combinados com um backup completo, eles permitem a recuperação pontual (PITR) — restaurando para qualquer momento específico, não apenas para a hora do último backup.

# Enable binlog retention (my.cnf)
[mysqld]
log_bin=mysql-bin
binlog_expire_logs_seconds=604800   # 7 days
binlog_format=ROW
gtid_mode=ON
enforce_gtid_consistency=ON

# Restore from backup then replay binlogs to a specific point
mysqlbinlog --start-datetime="2026-04-12 08:00:00" \
  --stop-datetime="2026-04-12 09:30:00" \
  mysql-bin.000042 mysql-bin.000043 | mysql -u root -p

# Or replay to a specific GTID position
mysqlbinlog --include-gtids="3c2d4f9e-d17e-ec59-9029-6aafa8accef8:1-5000" \
  mysql-bin.000042 | mysql -u root -p

Kubernetes

No Kubernetes, os backups devem ser executados como CronJobs em vez de comandos ad-hoc. Isso garante que os backups sejam automatizados, monitorados e possam ser alertados caso falhem.

apiVersion: batch/v1
kind: CronJob
metadata:
  name: mysql-backup
  namespace: production
spec:
  schedule: "0 2 * * *"
  concurrencyPolicy: Forbid
  successfulJobsHistoryLimit: 7
  failedJobsHistoryLimit: 3
  jobTemplate:
    spec:
      activeDeadlineSeconds: 7200
      template:
        spec:
          restartPolicy: OnFailure
          containers:
            - name: backup
              image: percona/percona-xtrabackup:8.0.35
              command:
                - /bin/sh
                - -c
                - |
                  BACKUP_DIR=/backups/$(date +%Y%m%d-%H%M%S)
                  mkdir -p $BACKUP_DIR
                  xtrabackup --backup \
                    --host=production-mysql.production.svc \
                    --user=backup_user \
                    --password=$BACKUP_PASSWORD \
                    --target-dir=$BACKUP_DIR \
                    --parallel=4 \
                    --compress
                  xtrabackup --prepare --target-dir=$BACKUP_DIR
                  # Upload to S3
                  aws s3 sync $BACKUP_DIR s3://mysql-backups/$(date +%Y%m%d)/
                  # Cleanup local
                  rm -rf $BACKUP_DIR
              env:
                - name: BACKUP_PASSWORD
                  valueFrom:
                    secretKeyRef:
                      name: mysql-backup-credentials
                      key: password
              volumeMounts:
                - name: backup-scratch
                  mountPath: /backups
              resources:
                requests:
                  cpu: "1"
                  memory: 2Gi
                limits:
                  cpu: "2"
                  memory: 4Gi
          volumes:
            - name: backup-scratch
              emptyDir:
                sizeLimit: 100Gi

com Monitoramento e Gerenciamento Percona (PMM)

Percona Monitoring and Management (PMM) é uma plataforma de monitoramento de código aberto desenvolvida especificamente para observabilidade de banco de dados. Embora o Prometheus e o Grafana forneçam monitoramento geral do Kubernetes, o PMM adiciona insights específicos do MySQL: análise de consulta (QAN) que identifica consultas lentas, painéis de atraso de replicação, taxas de acerto do buffer pool do InnoDB, contenção de bloqueio de tabela e muito mais.

# Deploy PMM Server on Kubernetes
apiVersion: apps/v1
kind: Deployment
metadata:
  name: pmm-server
  namespace: monitoring
spec:
  replicas: 1
  selector:
    matchLabels:
      app: pmm-server
  template:
    metadata:
      labels:
        app: pmm-server
    spec:
      containers:
        - name: pmm-server
          image: percona/pmm-server:2
          ports:
            - containerPort: 443
          env:
            - name: DISABLE_TELEMETRY
              value: "1"
          volumeMounts:
            - name: pmm-data
              mountPath: /srv
          resources:
            requests:
              cpu: "1"
              memory: 4Gi
            limits:
              cpu: "2"
              memory: 8Gi
      volumes:
        - name: pmm-data
          persistentVolumeClaim:
            claimName: pmm-data-pvc
---
apiVersion: v1
kind: Service
metadata:
  name: pmm-server
  namespace: monitoring
spec:
  type: ClusterIP
  selector:
    app: pmm-server
  ports:
    - port: 443
      targetPort: 443

# Register MySQL instances with PMM Client (run on each MySQL pod or sidecar)
pmm-admin config --server-url=https://admin:password@pmm-server.monitoring:443 --server-insecure-tls
pmm-admin add mysql \
  --username=pmm_monitor \
  --password=MonitorPass123 \
  --host=127.0.0.1 \
  --port=3306 \
  --query-source=perfschema \
  --service-name=mysql-node-1

PMM é particularmente valioso na produção. Ele captura todas as consultas executadas no servidor (via esquema de desempenho ou log de consultas lentas), agrega-as por impressão digital e mostra métricas como latência média, linhas examinadas versus linhas enviadas e tempo de bloqueio. É assim que você identifica as consultas que estão prejudicando o desempenho da sua aplicação.

A configuração padrão do MySQL é ajustada para uma carga de trabalho pequena e de uso geral. Ambientes de produção com servidores de banco de dados dedicados precisam de configurações significativamente diferentes. Aqui estão os parâmetros críticos e como dimensioná-los.

O buffer pool do InnoDB é onde o MySQL armazena em cache dados de tabela e índice na memória. É o parâmetro de configuração mais impactante. Para um servidor MySQL dedicado, configure-o para 70–80% da RAM disponível.

[mysqld]
# Memory: 16Gi container limit -> allocate ~12Gi to buffer pool
innodb_buffer_pool_size = 12G
innodb_buffer_pool_instances = 8          # 1 per GB (up to 64)
innodb_buffer_pool_chunk_size = 1536M     # pool_size / instances

O redo log absorve as gravações antes que elas sejam liberadas para os arquivos de dados. Logs de redo maiores reduzem a frequência de liberações de pontos de verificação e melhoram o rendimento de gravação. MySQL 8.0.30+ usainnodb_redo_log_capacityem vez do antigoinnodb_log_file_size.

[mysqld]
# MySQL 8.0.30+
innodb_redo_log_capacity = 4G

# MySQL 8.0.29 and earlier
# innodb_log_file_size = 2G
# innodb_log_files_in_group = 2

Compromisso entre durabilidade e desempenho

A combinação deinnodb_flush_log_at_trx_commitesync_binlogdetermina sua garantia de durabilidade.

• Máxima durabilidade(recomendado para produção):innodb_flush_log_at_trx_commit=1+sync_binlog=1. Cada transação é liberada para o redo log e o log binário no disco antes de ser reconhecida. Perda zero de dados em caso de falha.
• balanceado:innodb_flush_log_at_trx_commit=2+sync_binlog=1. O redo log é gravado no cache do sistema operacional por commit, mas apenas liberado no disco uma vez por segundo. Até 1 segundo de transações pode ser perdido em uma falha do sistema operacional (a falha do MySQL ainda é segura).
• Desempenho máximo(não recomendado para produção):innodb_flush_log_at_trx_commit=0+sync_binlog=0. As gravações são agrupadas e liberadas periodicamente. Risco de perder até 1 segundo de transações em qualquer falha.

[mysqld]
# Production durability settings
innodb_flush_log_at_trx_commit = 1
sync_binlog = 1
innodb_doublewrite = ON
innodb_checksum_algorithm = crc32

[mysqld]
# SSD-optimised I/O settings
innodb_io_capacity = 4000
innodb_io_capacity_max = 8000
innodb_read_io_threads = 8
innodb_write_io_threads = 8
innodb_flush_method = O_DIRECT
innodb_file_per_table = ON
innodb_open_files = 10000

e gerenciamento de threads

[mysqld]
max_connections = 500
max_connect_errors = 1000000
thread_cache_size = 64
table_open_cache = 4096
table_open_cache_instances = 16
back_log = 1500

# Thread pool (MySQL Enterprise or Percona)
thread_pool_size = 16
thread_pool_max_threads = 1000

[mysqld]
tmp_table_size = 64M
max_heap_table_size = 64M
sort_buffer_size = 4M
join_buffer_size = 4M
read_rnd_buffer_size = 2M

[mysqld]
# Identity
server-id = 1
report_host = mysql-node-1

# GTID Replication
gtid_mode = ON
enforce_gtid_consistency = ON
binlog_format = ROW
log_bin = mysql-bin
binlog_expire_logs_seconds = 604800
log_slave_updates = ON
relay_log_recovery = ON

# InnoDB Engine
innodb_buffer_pool_size = 12G
innodb_buffer_pool_instances = 8
innodb_redo_log_capacity = 4G
innodb_flush_log_at_trx_commit = 1
sync_binlog = 1
innodb_doublewrite = ON
innodb_flush_method = O_DIRECT
innodb_io_capacity = 4000
innodb_io_capacity_max = 8000
innodb_read_io_threads = 8
innodb_write_io_threads = 8
innodb_file_per_table = ON
innodb_open_files = 10000
innodb_adaptive_hash_index = ON
innodb_change_buffering = all

# Connections
max_connections = 500
max_connect_errors = 1000000
thread_cache_size = 64
table_open_cache = 4096
table_open_cache_instances = 16
back_log = 1500

# Temp / Sort
tmp_table_size = 64M
max_heap_table_size = 64M
sort_buffer_size = 4M
join_buffer_size = 4M

# Monitoring
performance_schema = ON
slow_query_log = ON
long_query_time = 1
log_queries_not_using_indexes = ON
log_throttle_queries_not_using_indexes = 60

# Security
local_infile = OFF
skip_name_resolve = ON
default_authentication_plugin = caching_sha2_password

# Group Replication (InnoDB Cluster)
plugin_load_add = 'group_replication.so'
plugin_load_add = 'mysql_clone.so'
loose-group_replication_start_on_boot = OFF
loose-group_replication_bootstrap_group = OFF
loose-group_replication_recovery_use_ssl = ON
loose-group_replication_ssl_mode = REQUIRED

Um sistema de alta disponibilidade que nunca foi testado sob condições de falha não é realmente altamente disponível – é uma hipótese. O teste de failover deve fazer parte de sua cadência operacional regular, e não algo que você descobre que funciona (ou não funciona) durante um incidente real.

# Test 1: Graceful primary failover (InnoDB Cluster)
mysqlsh gradmin@mysql-node-1:3306
var cluster = dba.getCluster()
cluster.setPrimaryInstance('gradmin@mysql-node-2:3306')
# Verify: cluster.status() should show node-2 as PRIMARY

# Test 2: Simulate primary crash
# On the primary node:
kill -9 $(pidof mysqld)
# Monitor: watch the cluster elect a new primary
# Verify: applications reconnect via MySQL Router within seconds

# Test 3: Network partition simulation
# On the primary node, block Group Replication port:
iptables -A INPUT -p tcp --dport 33061 -j DROP
iptables -A OUTPUT -p tcp --dport 33061 -j DROP
# The isolated node should be expelled; cluster continues with remaining members
# Cleanup:
iptables -D INPUT -p tcp --dport 33061 -j DROP
iptables -D OUTPUT -p tcp --dport 33061 -j DROP

# Test 4: Kubernetes pod deletion
kubectl delete pod mysql-0 -n production --grace-period=0 --force
# The StatefulSet controller recreates the pod
# The operator rejoins it to the cluster

Chaos Engineering com Litmus ou Chaos Mesh

As ferramentas de engenharia do caos estruturado injetam falhas sistematicamente e medem o raio da explosão. Chaos Mesh, um projeto CNCF, integra-se nativamente ao Kubernetes.

# Chaos Mesh: Kill a MySQL pod randomly
apiVersion: chaos-mesh.org/v1alpha1
kind: PodChaos
metadata:
  name: mysql-pod-kill
  namespace: production
spec:
  action: pod-kill
  mode: one
  selector:
    namespaces:
      - production
    labelSelectors:
      app.kubernetes.io/component: mysqld
  scheduler:
    cron: "0 */4 * * *"
---
# Chaos Mesh: Network delay between MySQL pods
apiVersion: chaos-mesh.org/v1alpha1
kind: NetworkChaos
metadata:
  name: mysql-network-delay
  namespace: production
spec:
  action: delay
  mode: one
  selector:
    namespaces:
      - production
    labelSelectors:
      app.kubernetes.io/component: mysqld
  delay:
    latency: "200ms"
    jitter: "50ms"
  duration: "5m"
  scheduler:
    cron: "30 */6 * * *"
---
# Chaos Mesh: Disk I/O stress
apiVersion: chaos-mesh.org/v1alpha1
kind: IOChaos
metadata:
  name: mysql-io-latency
  namespace: production
spec:
  action: latency
  mode: one
  selector:
    namespaces:
      - production
    labelSelectors:
      app.kubernetes.io/component: mysqld
  volumePath: /var/lib/mysql
  path: '*'
  delay: '100ms'
  percent: 50
  duration: '5m'

O que medir durante os testes de failover

• Objetivo de tempo de recuperação (RTO)— Quanto tempo desde a detecção da falha até a restauração do serviço? O cluster InnoDB normalmente atinge de 5 a 30 segundos. O cluster Percona XtraDB pode ser mais rápido porque não há eleição (todos os nós são graváveis).
• Objetivo de ponto de recuperação (RPO)— Quantos dados são perdidos durante o failover? Com a replicação síncrona (replicação de grupo no modo primário único, PXC), o RPO é zero para transações confirmadas. Com a replicação assíncrona (entre regiões do ClusterSet), o RPO é igual ao atraso da replicação.
• Taxa de erros de aplicativos— Quantas solicitações de aplicativos falham durante a janela de failover? Isso testa não apenas o failover do banco de dados, mas também a lógica de nova tentativa de conexão do seu aplicativo e a velocidade de redirecionamento do roteador MySQL.
• Tempo de drenagem da conexão— Quanto tempo levam as conexões existentes ao primário antigo para drenar e reconectar ao novo primário?

: Lista de verificação de falha do nó primário

1. Verifique se o cluster elegeu um novo primário:cluster.status()
2. Confirme se o roteador MySQL está roteando para o novo primário: verifique os logs do roteador e as contagens de conexões
3. Monitore o atraso de replicação nos secundários restantes:SELECT * FROM performance_schema.replication_group_member_stats
4. Se o nó com falha puder ser recuperado, junte-o novamente:cluster.rejoinInstance('gradmin@failed-node:3306')
5. Se o nó com falha não puder ser recuperado, remova-o e adicione um novo:cluster.removeInstance('gradmin@failed-node:3306', {force: true})
6. Verifique a integridade do cluster: todos os membros ONLINE, sem erros de replicação, agendamento de backup intacto
7. Atualize seu plano de capacidade: rodar com 2 nós significa que você tem tolerância zero a falhas até que o terceiro seja restaurado

devem abordar diversas questões de segurança além da autenticação básica.

em trânsito e em repouso

[mysqld]
# TLS for client connections
ssl_ca = /etc/mysql/certs/ca.pem
ssl_cert = /etc/mysql/certs/server-cert.pem
ssl_key = /etc/mysql/certs/server-key.pem
require_secure_transport = ON
tls_version = TLSv1.3

# Encryption at rest (InnoDB tablespace encryption)
early-plugin-load = keyring_file.so
keyring_file_data = /var/lib/mysql-keyring/keyring
innodb_undo_log_encrypt = ON
innodb_redo_log_encrypt = ON
default_table_encryption = ON

Kubernetes Segredos e Segredos Selados

# Never store database credentials in plain YAML
# Use Sealed Secrets or an external secret manager
apiVersion: bitnami.com/v1alpha1
kind: SealedSecret
metadata:
  name: mysql-root-credentials
  namespace: production
spec:
  encryptedData:
    rootUser: AgBy3i4OJSWK+PiTy...
    rootPassword: AgCtr7pJ2XQWK+Pi...
  template:
    metadata:
      name: mysql-root-credentials
      namespace: production
    type: Opaque

[mysqld]
# MySQL Enterprise Audit (or Percona Audit Log plugin)
plugin-load-add = audit_log.so
audit_log_format = JSON
audit_log_policy = LOGINS
audit_log_rotate_on_size = 100M
audit_log_rotations = 10

: Escolhendo sua arquitetura MySQL HA

A arquitetura correta depende de seus requisitos específicos. Aqui está uma estrutura de decisão.

• Nuvem única, preferência gerenciada, compatível com MySQL— Use Aurora (AWS), Servidor Flexível Business Critical (Azure) ou Cloud SQL Enterprise Plus (GCP). Eles fornecem a menor sobrecarga operacional.
• Nuvem única, autogerenciada, precisa de controle total do MySQL— Use o Operador MySQL ou o Operador Percona no EKS/AKS/GKE com classes de armazenamento nativas da nuvem.
• Multinuvem ou nuvem híbrida— Use o Operador Percona com PXC ou o Operador MySQL com Cluster InnoDB. A camada de abstração Kubernetes torna sua implantação MySQL portátil entre nuvens.
• Bare metal ou edge— Use k3s com Rancher, armazenamento Longhorn, MetalLB e Operador MySQL ou Operador Percona.
• Taxa de transferência máxima de gravação, multiprimário necessário— Use Percona XtraDB Cluster (Galera) com o Operador Percona. Todos os nós aceitam gravações com certificação síncrona.
• Distribuição global com recuperação de desastres— Use InnoDB ClusterSet com replicação assíncrona entre regiões. Aceite a compensação do RPO da replicação assíncrona pelos benefícios de latência das gravações locais.

para produção MySQL HA

Antes de declarar sua implantação MySQL HA pronta para produção, valide todos os itens desta lista de verificação.

1. Integridade do cluster— Todos os membros relatam o status ONLINE. A replicação de grupo não mostra erros.
2. Backups automatizados— CronJob ou backups gerenciados pelo operador executados dentro do cronograma. Backups verificados por testes periódicos de restauração.
3. Monitoramento— PMM ou Prometheus/Grafana coletando métricas MySQL. Alertas configurados para atraso de replicação, saturação de conexão, taxa de acerto do buffer pool abaixo de 99% e espaço em disco.
4. Failover testado— Failover primário testado nos últimos 30 dias. RTO e RPO medidos e dentro das metas de SLA.
5. Roteamento de conexão— Roteador MySQL ou ProxySQL com integridade verificada e balanceamento de carga. As strings de conexão do aplicativo apontam para o roteador, não para instâncias individuais do MySQL.
6. Segurança— TLS necessário para todas as conexões. Criptografia em repouso habilitada. Credenciais armazenadas em um gerenciador secreto. Registro de auditoria ativo. Usuários de banco de dados com privilégios mínimos para cada aplicativo.
7. Limites de recursos— Solicitações e limites de recursos Kubernetes definidos adequadamente. PodDisruptionOrçamentos em vigor. Pod antiafinidade espalhando pods MySQL entre zonas.
8. Plano de capacidade— Utilização de armazenamento monitorada com alertas em 70% e 85%. Expansão de volume testada. Procedimentos de dimensionamento vertical e horizontal documentados.
9. Runbooks— Procedimentos documentados para failover primário, substituição de nó, restauração de backup, atualização de versão e modo somente leitura de emergência.
10. Teste de caos— Experimentos regulares de caos programados para validar suposições de resiliência.

MySQL em produção não é uma escolha tecnológica única — é um sistema de decisões interligadas que abrange a camada de replicação, a plataforma de orquestração, o subsistema de armazenamento, a pilha de monitoramento e os processos operacionais em torno deles. Cluster InnoDB com replicação de grupo fornece a primitiva HA básica. Os operadores Kubernetes da Oracle e Percona automatizam o gerenciamento do ciclo de vida que, de outra forma, consumiria um tempo significativo de engenharia. Controle comercial de serviços gerenciados em nuvem por conveniência. As implantações bare metal com k3s, Rancher e Longhorn provam que você não precisa de um provedor de nuvem para executar MySQL HA de nível de produção.

A percepção mais crítica é que a alta disponibilidade é uma propriedade de todo o sistema, não apenas do banco de dados. Inclui como seu aplicativo lida com falhas e novas tentativas de conexão, como sua camada de proxy detecta e roteia nós com falha, como seu monitoramento alerta antes que os usuários percebam, como sua estratégia de backup permite a recuperação de cenários que o HA sozinho não consegue lidar e como sua equipe pratica procedimentos de failover para que sejam executados de forma limpa sob o estresse de um incidente real.

Construa-o deliberadamente, teste-o regularmente e trate seus runbooks como documentos vivos que evoluem com cada incidente e cada experimento de caos. É assim que a MySQL conquista seu lugar como plataforma de dados confiável e altamente disponível em produção.