APRENDER. PRATICAR. EVOLUIR.Conceito e mecanismo
mysqldump --single-transaction oferece um âmbito de consistência para tabelas InnoDB, não uma garantia universal para qualquer motor. MyISAM e MEMORY podem mudar durante o dump; DDL concorrente também pode invalidar resultados. Confirma motores, janela de schema e artefactos necessários antes de confiar na cópia. PITR combina um backup apropriado com binlogs posteriores e pontos de início e paragem validados. A retenção precisa de cobrir o intervalo necessário, não apenas o último ficheiro. Testa o restauro num destino isolado, incluindo contas, rotinas e configuração, e mede quando a aplicação fica utilizável.
Aplicação guiada
Replicação assíncrona permite atraso entre commit no source e aplicação na réplica. Uma leitura imediata precisa de contrato explícito: destino adequado ou espera controlada pelo GTID necessário. WAIT_FOR_EXECUTED_GTID_SET devolve zero em sucesso e um em timeout; não confundas esse retorno com um booleano de sucesso. Depois da espera, a leitura também deve usar uma snapshot adequada, evitando uma transação antiga que não veja o commit. Num erro fictício já replicado, promover a réplica atual não recupera o passado. Voltar a um ponto anterior pode excluir movimentos válidos posteriores. Preserva evidência e planeia reconciliação antes de reabrir escritas.
WAIT_FOR_EXECUTED_GTID_SET = 1: o prazo expirou; não há garantia de que a escrita requerida esteja visível.
Armadilhas comuns
Receiver ligado como réplica atual; 1 como sucesso; réplica como backup histórico; PITR como filtro de alterações erradas.
Tópicos relacionados: Tipos e contratos dos dados · Consultas determinísticas e planos · Transações InnoDB e caminhos de erro
Recuperação e leitura consistente precisam de condições observáveis, não apenas serviços ativos.
Referência: Backup and binary-log recovery · MySQL 9.7 LTS with InnoDB reference semantics