APRENDER. PRATICAR. EVOLUIR.Restaurar dados não recria todas as contas
O dump selecionou a base lab sem a opção users. Depois do restauro, a conta dr_runtime que existia na origem não estava no destino. O guião criou-a separadamente e começou por observar 1142 ao tentar ler accounts sem grants. Só depois atribuiu as permissões usadas pelo exemplo. A documentação oferece opções para exportar informação de contas, mas elas não foram executadas neste bloco. O ponto é tornar o âmbito explícito: dados, contas e privilégios são partes relacionadas da recuperação, e nenhuma deve ser presumida apenas porque as tabelas reapareceram. Regista também qual identidade executou o restauro e qual executou os testes da aplicação.
Testar o contexto dos objetos
A view e a procedure usam SQL SECURITY INVOKER. A conta runtime precisa de permissões para as referenciar e para ler os dados usados pelas suas definições. O trigger, por sua vez, executa no contexto do seu definer, que neste laboratório é root local. A inserção feita pela conta runtime criou uma linha de auditoria, embora essa conta recebesse 1142 ao tentar ler audit diretamente. Não transformes o definer privilegiado do ensaio numa recomendação de produção. A aceitação deve rever dependências, existência e privilégios dos definers, distinguindo acesso direto de efeitos executados por um objeto armazenado.
Confirmar leitura, escrita e efeitos associados
Depois dos grants, a conta runtime leu a view com duas contas e total 100, e a procedure devolveu o mesmo total. Inseriu depois NEW=10, recebeu id3 e passou a observar total 110. A consulta administrativa encontrou três linhas de auditoria, mostrando que o trigger restaurado também participou no fluxo. Estas verificações exercitam mais do que presença de objetos no catálogo. Ainda assim, são chamadas SQL locais com dados pequenos; não representam a aplicação completa, pool, autenticação remota ou carga esperada. Usa os resultados para definir critérios concretos e acrescenta os testes do serviço real que não foram cobertos pelo ensaio.
Rejeições esperadas também são critérios
A tentativa de repetir o código A devolveu 1062, e uma conta BAD com saldo negativo devolveu 3819 por violação de CHECK. Continuaram a existir três contas e três linhas de auditoria. O restauro útil conserva tanto operações permitidas como restrições que impedem dados inválidos. Não concluas a revisão só porque uma escrita válida funcionou. Define entradas inválidas relevantes ao contrato e confirma que são rejeitadas sem efeitos laterais inesperados. No laboratório, verificaram-se contagens depois das duas falhas; não se mediram todas as invariantes possíveis da aplicação. A aceitação funcional continua a precisar de casos representativos acordados com os responsáveis pelos dados.
Uma importação falhada pode deixar trabalho
O ficheiro de falha insere before-error, referencia uma tabela inexistente e só depois tenta inserir after-error. Executado pelo cliente mysql em batch, sem force e sem uma transação que envolva o ficheiro, termina com 1146. A primeira nota ficou confirmada e a última não foi executada. Portanto, parar no erro não torna o ficheiro atomicamente reversível. Antes de repetir, identifica o que já foi aplicado e escolhe uma estratégia apropriada. No laboratório, o destino descartável foi recriado e recebeu de novo o dump original; essa operação recuperou duas contas e duas auditorias, perdendo deliberadamente a escrita NEW feita no destino de teste.
Encerrar o ensaio e declarar o que falta
Os dezasseis grupos usam dois servidores MySQL 9.7.2 descartáveis, sockets privados, quatro ligações persistentes e clientes CLI adicionais. Uma conta runtime sem privilégios administrativos executou os testes permitidos e as rejeições previstas. As passwords vazias pertencem apenas a este ambiente local descartável; não validam uma configuração de autenticação real. Os clientes e servidores terminaram e os diretórios temporários foram removidos. Não houve base de produção, TCP, TLS, réplica, recuperação por binary logs, DDL concorrente, crash ou benchmark. O handover deve conservar esses limites e pedir a evidência operacional ainda necessária, incluindo proteção do backup, ponto de recuperação, carga e revisão independente.
-- Target-only synthetic lab account; empty password is not a production pattern.
CREATE USER 'dr_runtime'@'localhost' IDENTIFIED BY '';
GRANT SELECT,INSERT ON lab.accounts TO 'dr_runtime'@'localhost';
GRANT SELECT ON lab.totals TO 'dr_runtime'@'localhost';
GRANT EXECUTE ON PROCEDURE lab.read_total TO 'dr_runtime'@'localhost';
-- Verify allowed operations and expected denials using that account.A conta runtime recebeu 1142 antes dos grants; depois leu o total, inseriu id3 e acionou auditoria sem ter acesso direto à tabela audit.
Armadilhas comuns
Restauro como superutilizador igual a aplicação funcional; erro de importação como rollback total; hash como prova de recuperação de negócio.
Tópicos relacionados: Backup lógico e inventário de objetos · Permissões e aceitação da recuperação
Aceita o restauro por resultados observados e limites explícitos, com um plano para trabalho parcial e alterações posteriores ao backup.
Referência: Stored object access control · MySQL 9.7 LTS with InnoDB reference semantics