Skip to main content
SQLOZ
Funcionalidades Documentação Preços Roteiro Blog A nossa história Disponível na Mac App Store
Chapter 17 DBA & Production Safety

Capítulo 17: OzOSC - Alterações de Schema Sem Downtime

Informação: Este capítulo descreve o design do OzOSC (Online Schema Change) e seus limites de suporte atuais. Controles de execução nativa e recuperação estão disponíveis para tabelas suportadas em MySQL e MariaDB, condicionados a verificações ativas de segurança e aprovação explícita.

Neste capítulo:

17.1 Visão Geral

Executar um comando ALTER TABLE convencional em uma tabela grande em produção introduz riscos críticos:

  1. Bloqueio de tabela (Table lock): O motor de banco de dados bloqueia leituras e escritas na tabela.
  2. Interrupção de serviço (Downtime): A aplicação não consegue gravar no banco de dados, resultando em timeouts para os usuários.
  3. Alto risco operacional: Operações longas que forem interrompidas podem corromper dados ou travar o subsistema de replicação.

A análise de plano do OzOSC realiza verificações ativas e em modo somente leitura da conexão, metadados, identidade do servidor e integridade da chave primária. O fluxo de execução protegido cria um backup verificado, prepara uma shadow table isolada pelo plano, copia registros em lotes (chunks) e realiza o swap atômico final apenas se todas as provas ativas forem validadas. Qualquer prova incompleta ou ambígua aciona fail-closed imediato.

17.2 Status Atual de Suporte

O OzOSC atualmente suporta o pipeline nativo de MySQL/MariaDB para tabelas qualificadas que possuam chave primária verificada e metadados suportados. SQLite e PostgreSQL não utilizam este pipeline OSC nativo. Tabelas com colunas geradas incompatíveis, chaves estrangeiras complexas ou triggers preexistentes são rejeitadas durante a fase de validação. A aprovação explícita de operação destrutiva, um plano de contingência e as capacidades reais do banco continuam sendo obrigatórias antes da execução.

17.3 Operação Planejada

[ Tabela Ativa: orders ] --(Cópia delta via triggers)--> [ Shadow Table: _orders_sqloz_osc ]
   (Leituras/escritas ativas continuam)                      (ALTER TABLE aplicado)
                                                                       |
                                                           (Swap atômico de tabela − 1 ms)
                                                                       v
                                                         [ Nova Tabela Ativa: orders ]

Estas são as etapas do fluxo protegido. As fases potencialmente destrutivas só são iniciadas após validação rigorosa:

  1. Criação da shadow table: Após comprovação de elegibilidade e backup, uma tabela sombra vazia, idêntica à tabela de destino, é gerada.
  2. Aplicação da alteração de schema na shadow table: O ALTER TABLE é executado na tabela sombra vazia, e não na tabela ativa (duração de milissegundos).
  3. Sincronização delta via triggers: Triggers temporários espelham operações INSERT, UPDATE e DELETE em tempo real da tabela de produção para a shadow table enquanto os dados são copiados.
  4. Cópia de dados particionada (Chunked copy): Os dados preexistentes são transferidos em lotes controlados para evitar contenção de buffer pool e replicação enquanto a aplicação continua operando sem interrupção.
  5. Swap atômico de tabelas: Após a conclusão da cópia e verificação de integridade do delta, o journal e os metadados são reavaliados antes de renomear as tabelas atomicamente via RENAME TABLE. A tabela antiga é preservada até a conclusão da fase de limpeza verificada.

Se o processo for interrompido, acesse Refresh Recovery no painel OzOSC. O painel disponibiliza exclusivamente as ações sustentadas pelo inventário durável:

  • Complete cleanup: Conclui a remoção de artefatos temporários após um swap comprovado.
  • Reconcile swap: Avança a operação de renomeação pendente após validar identidade e layout.
  • Resume copy: Retoma uma cópia pré-swap respaldada por checkpoints, backups válidos, triggers e cursores íntegros.
  • Abort preparation: Exige confirmação explícita e remove apenas artefatos temporários do plano, preservando integralmente a tabela original e seu backup.

Registros inconsistentes ou ambíguos permanecem bloqueados para diagnóstico manual; eles nunca são ignorados ou marcados como concluídos de forma tácita.

Aviso: Comandos DDL no MySQL/MariaDB não oferecem suporte geral a transações com rollback. O OzOSC não promete zero downtime absoluto ou limpeza desassistida sob qualquer falha; evidências ambíguas bloqueiam a operação para garantir integridade.

17.4 Acompanhamento de Progresso em Tempo Real

Durante a execução, o painel exibe:

  • Velocidade de cópia ativa (Linhas/seg): Taxa de transferência de linhas por segundo.
  • Tempo estimado restante (ETA): Previsão de conclusão com base no throughput atual.
  • Cancelamento seguro: A solicitação de cancelamento propaga a interrupção de forma controlada e o painel detalha o status dos artefatos remanescentes.

Aviso: O OzOSC opera exclusivamente na tabela designada. Não interfira no nome da shadow table nem execute outros comandos ALTER concorrentes durante a migração.

Este documento descreve o fluxo implementado e suas salvaguardas de segurança. Ele não substitui a validação de aceite do release na interface do SQLOZ.

Tópicos Relacionados