Data Management:Alteração de dados padrão

Etapa 1: Configure e envie o ticket

1. Faça login no DMS 5.0.

2. Posicione o ponteiro sobre o ícone no canto superior esquerdo do console do DMS e escolha All Features > Database Development > Data Change > Normal Data Modify.

   Nota

   Se você utilizar o console do DMS no modo normal, escolha Database Development > Data Change > Normal Data Modify na barra de navegação superior.

3. Na página Data Change Ticket Request, configure os parâmetros do ticket. A tabela a seguir descreve alguns desses parâmetros.

   Nota

   • O exemplo a seguir demonstra como configurar os parâmetros para uma instância no modo Security Collaboration. Os parâmetros podem variar caso você selecione uma instância no modo Stable Change.

   • O recurso para alterar instâncias de source de dados está sendo implementado em fases.

   Item de configuração	Obrigatório	Descrição
   Change Target	Sim	Selecione Database ou Data Source Instance. Nota No momento, apenas instâncias MySQL dos seguintes tipos podem ser selecionadas para alterações de instância de source de dados: RDS MySQL, PolarDB for MySQL e AnalyticDB for MySQL.
   Database ou Data Source Instance	Sim	Pesquise e selecione um banco de dados ou instância para o qual você tenha permissões de alteração. Nota No momento, é possível selecionar apenas uma instância por alteração de instância de source de dados.
   Reason Category	Sim	Selecione um motivo para a alteração de dados, facilitando a localização posterior. Nota Os administradores podem configure a lista de categorias de motivo na seção Operations Management > Configuration Management. Para mais informações, consulte Configuration management.
   Business Background	Sim	Forneça uma descrição detalhada do motivo ou objetivo da alteração para reduzir a sobrecarga de comunicação.
   Execution Method	Sim	Selecione um método de execução para o ticket: Após a aprovação, o solicitante executa a operação. Execução automática após a aprovação. Execução pelo último aprovador. Nota Os administradores podem modifique a lista de métodos de execução na seção Operations Management > Configuration Management. Para mais informações, consulte Configuration management.
   Affected Rows	Sim	Estime o número de linhas de dados que esta alteração afetará.
   Change SQL	Sim	Selecione Text ou Attachment.
   SQL Text	Sim	Este item de configuração aparece somente se você definir Change SQL como Text. Na caixa de texto SQL, insira as instruções SQL que podem ser executadas diretamente. Nota Separe múltiplas instruções SQL com ponto e vírgula (;). Se o alvo da alteração for uma instância, adicione o nome do banco de dados antes de cada nome de tabela nas instruções SQL. Use o formato ${dbName}.${tableName}. Ao enviar o ticket, o sistema verifica automaticamente a sintaxe SQL. Caso a sintaxe esteja incorreta, o envio do ticket não será permitido.
   Attachment	Sim	Este item de configuração aparece somente se você definir Change SQL como Attachment. Faça o upload do anexo SQL para a alteração. Nota O anexo pode ser um arquivo .txt, .zip ou .sql. O tamanho máximo do arquivo é 15 MB.
   Rollback SQL	Não	Selecione Text ou Attachment. Nota O DMS preenche automaticamente as informações de Rollback SQL ao criar um ticket de rollback somente se você inserir o SQL de rollback ou fazer o upload de um arquivo de rollback. Caso contrário, você deverá inserir as informações manualmente.
   SQL Text	Não	Este item de configuração aparece somente se você definir Rollback SQL como Text. Insira as instruções SQL de rollback. O Rollback SQL é o script inverso do Change SQL.
   Attachment	Não	Este item de configuração aparece somente se você definir Rollback SQL como Attachment. Clique em Upload File para fazer o upload do anexo SQL de rollback. Nota O anexo pode ser um arquivo .txt, .zip ou .sql. O tamanho máximo do arquivo é 15 MB.
   Stakeholders	Não	Os stakeholders especificados podem visualizar o ticket e colaborar nele. Usuários que não sejam stakeholders não podem visualizar o ticket, exceto administradores e DBAs.
   Ticket Attachment	Não	Faça o upload de um anexo para fornecer informações adicionais ao ticket atual.

4. Clique em Submit Request.

Etapa 2: Verificar o SQL previamente

Após enviar o ticket, o sistema executa automaticamente uma verificação prévia. Se a verificação falhar, modifique as instruções SQL conforme as orientações exibidas e tente novamente.

Quando a verificação prévia for concluída com êxito, o status de cada item (SQL Splitting, Type Check, Permission Check, SQL Review e Check Scanned Rows) será Passed. O campo Affected Rows também é exibido. O número real de linhas afetadas depende do comportamento de execução do SQL.

Etapa 3: Aprovar o ticket

Após a verificação prévia ser concluída com êxito, clique em Submit for Approval. Na caixa de diálogo Notice, clique em OK.

A caixa de diálogo Notice exibe informações de validação, como o número de bancos de dados físicos, o número de instruções SQL e a estimativa de linhas afetadas. Caso o número de linhas afetadas verificado pelo sistema seja diferente do valor informado por você, uma mensagem de aviso em vermelho será exibida. Confirme as informações antes de enviar o ticket.

Etapa 4: Execute a alteração

1. Após a aprovação do ticket, clique em Execute Change. Na caixa de diálogo Task Settings, defina os parâmetros de execução da tarefa e clique em Execute.

   Nota

   • Ao criar o ticket, se você definir Execution Method como Execute automatically after approval, o sistema ignora esta etapa.

   • Ao reiniciar uma tarefa pausada, o script retoma a execução a partir do ponto em que foi interrompido.

   Item de configuração	Descrição
   Execution Policy	Selecione uma política de execução: Execute Immediately: A tarefa é iniciada imediatamente após você clicar em Execute. Scheduled Execution: Especifique um horário de início para a tarefa. Por exemplo, execute a tarefa às 00:00:00 do dia 22 de maio de 2024. Nota O horário de execução real de uma tarefa agendada pode ter uma margem de erro de ±1 minuto.
   Specify End Time	Especifique um horário de término para a tarefa. Se a tarefa não for concluída até o horário especificado, o sistema interrompe a execução das tarefas SQL restantes. Isso evita que as tarefas sejam executadas durante os horários de pico e causem impacto nas operações do negócio. Nota O horário de término real da tarefa pode ter uma margem de erro de ±1 minuto.
   Enable Global Transaction	Selecione se deseja ativar transações globais. Por padrão, esse recurso está desativado. Ativar: em caso de falha na execução, todas as alterações são revertidas. Aplica-se apenas a instruções DML, não a instruções DDL. Desativar: as tarefas SQL são enviadas uma a uma. Se uma tarefa falhar, a execução é interrompida, mas nenhuma alteração é revertida.
   Enable Backup	Selecione se deseja ativar backups. Por padrão, esse recurso está ativado. Quando ativado, você pode usar o arquivo de backup para restaurar os dados rapidamente depois. Nota O backup de dados é compatível somente com a execução de instruções UPDATE e DELETE. O backup de dados não é compatível com MongoDB e Redis. É possível realizar backup de no máximo 500.000 linhas de dados. O excedente é truncado automaticamente. O backup de dados não é compatível com tabelas associadas. Ativar: antes de executar instruções UPDATE ou DELETE, o sistema gera automaticamente um anexo de script de backup. Se o banco de dados for MySQL ou MariaDB, é gerada uma instrução de backup REPLACE INTO. Nota MySQL inclui: RDS MySQL, PolarDB for MySQL, PolarDB-X e outras fontes MySQL. Para bancos de dados com um mecanismo diferente de MySQL ou MariaDB, é gerada uma instrução de backup INSERT. Desativar: nenhum anexo de backup é gerado.
   Enable Primary/Standby Check	Ao ativar a verificação de primário/standby para o banco de dados, você garante a sincronização de dados em tempo real entre as instâncias primária e standby. Isso melhora a alta disponibilidade do banco de dados e agiliza a recuperação de desastres.
   Grayscale Type	A política para executar instruções SQL em lotes. No Grayscale: o DMS executa automaticamente todas as instruções SQL da tarefa. Pause after the first SQL statement succeeds: após a execução bem-sucedida da primeira instrução SQL, o DMS pausa automaticamente a execução. Para continuar, clique em Retry. As instruções SQL restantes serão executadas de uma vez, sem pausas adicionais. Pause after each SQL statement succeeds: a execução é pausada após cada instrução SQL. É necessário clicar manualmente em Retry para executar a próxima instrução SQL.

   Nota

   A execução das tarefas SQL é monitorada pelo módulo Security Rules, especificamente pela seção SQL Execution Control. Isso inclui mecanismos como timeout de bloqueio do banco de dados antes da execução SQL, verificações de carga do banco de dados e políticas de sleep após a execução SQL. Para modificar as configurações padrão dos pontos de detecção, consulte Configure SQL execution control.

   • Após a execução bem-sucedida do ticket, na coluna Actions, clique em Details para visualizar detalhes como status de execução, número de execuções, número de linhas afetadas, script de execução e logs.

   • Após a execução bem-sucedida do ticket, acesse a janela SQL do banco de dados de destino para verificar se a alteração de dados atende às suas expectativas.

2. Opcional: Crie um ticket de rollback para restaurar rapidamente os dados originais.

   Se a alteração de dados não atender às suas expectativas, crie um ticket de rollback ou envie manualmente um ticket de alteração de dados padrão para restaurar rapidamente os dados originais. As etapas a seguir mostram como criar um ticket de rollback:

   1. Na área Execution do ticket, clique em Generate Rollback Ticket à direita da tarefa de destino.

   2. Selecione uma Source de rollback e clique em OK. Há suporte para três fontes de rollback:

      • Texto de rollback: o texto de rollback inserido durante a configuração do ticket.

      • Anexo de rollback: o anexo de rollback enviado durante a configuração do ticket.

      • Arquivo de backup: o anexo de backup gerado durante a execução do ticket.

        Nota

        Para restaurar os dados originais usando um arquivo de backup, ative os backups antes de executar a alteração.

   3. (Opcional): modifique o texto de rollback, o anexo ou o arquivo de backup conforme necessário.

      • Texto de rollback: edite diretamente na caixa de texto SQL.

      • Anexo de rollback ou arquivo de backup: baixe o anexo para o computador local, faça as modificações necessárias e reenvie-o ao ticket de rollback.

   4. Após confirmar que as informações de rollback estão corretas, clique em Submit Request. O processo subsequente do ticket é idêntico ao de um ticket de alteração de dados padrão.

3. Baixe o arquivo de backup.

   Baixe o arquivo de backup para salvá-lo ou modificá-lo antes de enviá-lo ao DMS.

   1. Na coluna Actions, clique em Download Backup. O arquivo de backup contém as seguintes partes principais:

      • A instrução SQL original da alteração.

      • A instrução SQL de consulta para a alteração de dados.

      • O SQL de backup da alteração de dados.

      Por exemplo:

      /*
      [Database]:   rds@rm-bp144d5ky4l4rli0417****.mysql.rds.aliyuncs.com:3306[rds mysql]
      */
      /*
      [SQL]:
      UPDATE t_order
      SET product_id = 88
      WHERE id = 10054
      [BACKUP SQL]:    SELECT *
      FROM t_order
      WHERE id = 10054
      */
      REPLACE INTO `t_order`(`id`,`product_id`,`gmt_create`,`gmt_modified`,`customer_id`,`price`,`status`,`province`) VALUES
      (10054,81,'2021-12-14 09:44:44','2021-12-14 09:44:44',71,63.45,'Success','Hangzhou');
                                          

   2. Extraia o backup statement do arquivo de backup. Após confirmar que o backup statement está correto, envie um novo ticket padrão de alteração de dados para restaurar os dados conforme necessário.

      Nota

      Se um statement UPDATE foi executado por engano e o backup statement for um statement INSERT, determine o método de recuperação por conta própria.

4. (Opcional) Verifique se a alteração atende às expectativas.

   1. Na página de detalhes do ticket, na área Basic Information, posicione o ponteiro do mouse sobre o nome do banco de dados e clique em Query.

   2. Você será redirecionado para o SQL Console. Consulte os dados da tabela para verificar se atendem às suas expectativas.

Perguntas Frequentes

• P: Ao enviar uma alteração de dados no DMS, a operação falha com a mensagem de erro: "The topology of the published database XXX is inconsistent with the topology of the change baseline database. Please correct the topology and try again."

  R: Em uma alteração de banco de dados lógico, a estrutura de sharding do banco de dados de baseline e do banco de dados de produção deve ser consistente. Por exemplo, se o banco de dados de baseline tiver 8 shards e 256 tabelas, o banco de dados de produção também deve ter 8 shards e 256 tabelas. Essa consistência é necessária porque o script para alterações online é gerado comparando o banco de dados de produção com o banco de dados de baseline.

• P: Ao crie um ticket de alteração de dados no DMS, não consigo encontrar o banco de dados.

  R: A lista suspensa de bancos de dados pode não exibir todos os bancos disponíveis — normalmente ela mostra apenas os utilizados recentemente. Caso o banco de dados não apareça na lista, pesquise por ele manualmente. Para Redis, realize a busca pelo nome do banco de dados. Bancos de dados RDS PostgreSQL funcionam de forma diferente: pesquise pelo nome do schema. Por exemplo, ao pesquisar por public, o resultado retorna bancos de dados no formato public:postgres. Você também pode copiar a string de conexão da janela SQL Console e utilizá-la na pesquisa.

• P: Ao selecione vários bancos de dados e envie um ticket de alteração de dados, em quais situações as alterações são consolidadas em um único ticket e em quais são divididas em múltiplos tickets?

  R: A consolidação ou divisão dos tickets é determinada pelas regras de segurança e pelos proprietários dos bancos de dados selecionados:

  • Se os bancos de dados utilizam a mesma regra de segurança e têm o mesmo proprietário, as alterações são consolidadas em um único ticket contendo múltiplas tarefas.

  • Se os bancos de dados utilizam regras de segurança diferentes ou têm proprietários distintos, as alterações são divididas em múltiplos sub-tickets.