Percona Operator for MySQL 1.3.0 traz tuning automático e failover sem perda de dados

Percona lançou o Percona Operator for MySQL↳MySQL8 conteúdosMySQL + Adminer + Docker Compose: montando rapidamente um ambiente para usoData · abr 2019Banco de dados MYSQL no PHPStormDev (Back & Front) · jul 2019Criando um ambiente de desenvolvimento PHP mínimo com Docker – Parte 3Dev (Back & Front) · out 2019Ver tudo em Data → 1.3.0 em 29 de outubro de 2026, segundo o post oficial no blog da empresa. O operador é o pacote que administra clusters MySQL dentro do Kubernetes↳Kubernetes18 conteúdosGerenciamento de infraestrutura multicloud com Kubernetes proporciona otimização e economiaDevSecOps · set 2021Azure Kubernetes Services – AKS: referências gratuitas e dicas para solução de problemas comunsDevSecOps · abr 2019Kubernetes em produção: o que ninguém te conta e você aprende tarde demaisDev (Back & Front) · abr 2026Ver tudo em DevSecOps →, e esta versão mexe em três pontos que qualquer equipe que roda banco em contêiner sente no dia a dia: configuração automática do MySQL, failover sem perda de transações em clusters assíncronos e recuperação pontual (PITR) sobre binlogs criptografados.

Antes de qualquer feature nova, dois comportamentos padrão mudaram, e quem for atualizar precisa revisar os dois.

O que quebra silenciosamente no upgrade

A eleição de líder do operador agora vem ligada por padrão. Para a imensa maioria dos deploys isso é o comportamento correto; quem mantinha réplica única do controller por algum motivo específico (ambiente local, debug) precisa setar PSO_LEADER_ELECTION_ENABLED=false explicitamente no Deployment do operador.

A mudança que pega gente desprevenida é outra: clusters assíncronos agora precisam ter backup habilitado. A razão é técnica, não burocrática: o failover sem perda de dados, detalhado abaixo, depende de ler os binary logs do primário que caiu, e o operador usa a mesma infraestrutura de backup para isso. Sem backup configurado, o CRD recusa reconciliar o cluster assíncrono.

Há duas saídas:

• Habilitar backup no cluster, caminho recomendado pela própria Percona.
• Desligar explicitamente a proteção com a flag de escape.

spec:
  unsafeFlags:
    asyncFailoverWithPossibleDataLoss: true

Essa segunda opção restaura o comportamento anterior ao 1.3.0: failover rápido, mas transações confirmadas no primário antigo que ainda não chegaram à réplica escolhida são perdidas. Clusters em Group Replication não são afetados por nenhuma das duas mudanças.

Autopilot tuning: o operador calcula o my.cnf pelo tamanho do pod

Ajustar parâmetros do MySQL para o shape de um pod é trabalho que toda equipe faz uma vez e depois esquece de repetir. Quando o limite de CPU ou memória do pod muda, a configuração manual quase nunca acompanha. O bloco spec.mysql.autoConfig resolve isso: o operador passa a calcular a configuração do MySQL a partir dos recursos declarados no pod e do tipo de carga de trabalho informado.

Três campos controlam o comportamento: enabled liga o recurso, loadType descreve o perfil de carga (mostlyReads, someWrites, equalReadsWrites ou heavyWrites) e version informa qual versão do MySQL está sendo ajustada. O CRD exige que mysql.resources traga limite de CPU e memória quando autoConfig.enabled é true: sem esses limites o operador não tem base de cálculo.

apiVersion: ps.percona.com/v1
kind: PerconaServerMySQL
metadata:
  name: cluster1
spec:
  mysql:
    size: 3
    resources:
      limits:
        memory: 8Gi
        cpu: 4
    autoConfig:
      enabled: true
      loadType: someWrites
      version: 8.4.0

Com esse bloco, o operador dimensiona o buffer pool e parâmetros correlatos a partir de 8 GiB de memória e 4 CPUs, inclina a configuração para uma carga mista com alguma escrita e ajusta tudo para o MySQL 8.4.0. Mudar o limite de recursos ou o loadType faz o operador recalcular automaticamente.

Nem toda variável aceita mudança a quente. Onde o MySQL permite, o operador aplica a mudança com SET GLOBAL, sem reiniciar o pod; variáveis estáticas ainda exigem reinício, que o operador faz pod a pod, em sequência, para não tirar o cluster do ar de uma vez.

Falha sem perder dados: o que acontece entre a queda e a promoção

Replicação assíncrona, por definição, confirma a transação ao cliente antes de qualquer réplica tê-la recebido. Se o primário cai com transações no binlog que nenhuma réplica leu ainda, essas transações somem, mesmo com um controlador de alta disponibilidade bem configurado. É esse buraco que o 1.3.0 ataca.

O operador estende o sidecar do xtrabackup, presente em todo pod MySQL, com um endpoint POST /failover/stream na porta 6450, que serve os binary logs como stream tar. Quando o primário falha, a ferramenta de failover roda na réplica escolhida e segue uma sequência de resgate:

1. Sonda o primário que falhou e recua se ele voltou sozinho.
2. Para a replicação e esvazia os relay logs.
3. Lê Read_Source_Log_File e Read_Source_Log_Pos para encontrar a lacuna exata.
4. Busca os binlogs faltantes no sidecar do primário caído.
5. Corta os binlogs recuperados no último ponto de transação completa.
6. Emenda esse trecho no último relay log fechado.
7. Liga a thread SQL e espera até aplicar cada transação faltante.
8. Só então o orquestrador promove a réplica escolhida.

Isso tem um custo: tempo. O failover tem um orçamento padrão de uma hora para o pod do primário caído ficar alcançável e as transações faltantes serem aplicadas, contado a partir da primeira tentativa, não por retry. Esgotado o prazo, a política de on-timeout decide o desfecho: Abort mantém o cluster travado esperando intervenção, ForceWithPossibleDataLoss promove mesmo assim. O mecanismo exige apenas que o sidecar do primário responda, não que o mysqld esteja de pé: um pod com o processo MySQL travado mas o sidecar vivo ainda serve binlog.

PITR com binlogs criptografados: a chave sai do pod

O binlog server do operador já enviava binary logs para object storage para permitir recuperação pontual. A partir do 1.3.0, esses arquivos podem ser criptografados em repouso, com a chave guardada num Secret do Kubernetes em vez de viajar em cada pod MySQL.

O esquema é de envelope encryption: uma chave de dados (DEK) por arquivo criptografa cada binlog, e essa DEK é embrulhada sob uma chave de chave (KEK) que o operador lê de um Secret de keyring. Três campos controlam isso: spec.backup.pitr.binlogServer.storage.encryption.cipher define a cifra simétrica (AES-256-CTR por padrão), kekId nomeia a entrada da KEK dentro do keyring, e keyringSecret aponta para o Secret que guarda o arquivo de keyring (chave padrão keyring.json).

Na restauração, a ferramenta de PITR lê o keyring, localiza a KEK referenciada nos metadados do arquivo, desembrulha a chave e passa os eventos decifrados pelo mysqlbinlog até o MySQL restaurado. Se o keyring não existe ou a KEK citada não está nele, a restauração falha rápido e de forma explícita, em vez de produzir uma recuperação parcial silenciosa, o tipo de falha que só aparece numa auditoria.

O resto do pacote: menos coisa fora do CR

Várias mudanças menores empurram trabalho de runbook manual para dentro da spec declarativa:

• Usuários de aplicação passam a ser declarados na lista spec.users, com name, passwordSecretRef opcional, dbs, hosts, grants e withGrantOption.
• O caminho de backup aceita uma CA customizada, o que destrava apontar para MinIO ou outro S3-compatível atrás de uma CA corporativa própria.
• O bloco de TLS pode referenciar um ClusterIssuer do cert-manager em vez de um issuer de namespace.
• Rotação de TLS sem reiniciar pod: o operador mescla a CA antiga com a nova, recarrega os certificados a quente e só descarta a raiz antiga depois de confirmar a propagação.
• Backup com prazo: um backup que estoura o deadline falha rápido com status claro, em vez de ficar pendurado.
• Parâmetros de eleição de líder configuráveis via variáveis PSO_LEADER_ELECTION_*.
• Log do operador persistente entre reinícios do controller.
• DigitalOcean Kubernetes entra como plataforma oficialmente suportada, e o MySQL 9.7 entra na matriz de versões suportadas.

Troca de tipo de replicação em tech preview, rejoin de ClusterSet, relatório de atraso de replicação, clusters assíncronos com número par de réplicas e bootstrap assíncrono a partir de backup completam a lista, segundo as notas de versão.

Quando vale ativar tudo e quando não vale

O autoConfig só compensa quando o pod tem limites de recursos estáveis e declarados; num cluster de desenvolvimento onde CPU e memória mudam a cada deploy, o recálculo constante pode gerar reinícios desnecessários para variáveis estáticas. Vale mais a pena em produção, onde o shape do pod é parte do contrato de capacidade.

O failover sem perda de dados resolve um problema real de replicação assíncrona, mas troca velocidade por integridade: o orçamento padrão de uma hora é alto para quem prioriza tempo de indisponibilidade sobre a última transação. Equipes que já aceitam esse risco por outro motivo, e documentam isso, têm na flag asyncFailoverWithPossibleDataLoss: true o caminho de volta ao comportamento anterior, sem perder as outras novidades do release.

A criptografia de binlog para PITR tem custo de operação, não de performance: alguém precisa gerir o keyring e garantir que ele sobreviva ao pod, ao namespace e ao desastre que motivou o PITR em primeiro lugar. Para quem já tem um processo de gestão de chaves alimentando o Secret, é um ajuste de configuração. Para quem não tem, a prioridade é construir esse processo antes de ligar o encryption.cipher, porque um keyring perdido inviabiliza a restauração por completo.

Fonte: Percona Database Blog