Compartilhar via

Atualização de versão principal no Banco de Dados do Azure para MySQL – Servidor flexível

  • Artigo

APLICA-SE A: Banco de Dados do Azure para MySQL – Servidor flexível

Observação

Este artigo contém referências ao termo servidor subordinado, um termo que a Microsoft não usa mais. Quando o termo for removido do software, também o removeremos deste artigo.

Este artigo descreve como é possível atualizar a versão principal no local do MySQL no Banco de Dados do Azure para MySQL – servidor flexível. Esse recurso permite que os clientes executem atualizações no local de seus servidores MySQL 5.7 para o MySQL 8.0, sem nenhuma movimentação de dados ou a necessidade de fazer alterações na cadeia de conexão do aplicativo.

Importante

  • A duração do tempo de inatividade varia de acordo com o tamanho da instância do banco de dados e o número de tabelas.
  • Ao iniciar uma atualização de versão principal para o Banco de Dados do Azure para MySQL – servidor flexível por meio da API REST ou do SDK, evite modificar outras propriedades do serviço na mesma solicitação. As alterações simultâneas não são permitidas e podem levar a resultados não esperados ou falha na solicitação. Realize modificações de propriedade em operações separadas após a conclusão da atualização.
  • Algumas cargas de trabalho podem não apresentar desempenho aprimorado após a atualização da versão 5.7 para a 8.0. Sugerimos que você avalie o desempenho de sua carga de trabalho criando primeiro um servidor de réplica (como um servidor de teste), promovendo-o para um servidor autônomo e, em seguida, executando a carga de trabalho no servidor de teste antes de implementar a atualização em um ambiente de produção.
  • A atualização da versão principal do MySQL é irreversível. Sua implantação poderá falhar se a validação identificar que o servidor está configurado com recursos removidos ou preteridos. Você pode fazer as alterações de configuração necessárias no servidor e tentar atualizar novamente.

Pré-requisitos

  • As Réplicas de Leitura com a versão 5.7 do MySQL devem ser atualizadas antes que o Servidor Primário para replicação seja compatível entre diferentes versões do MySQL, leia mais sobre Compatibilidade de replicação entre versões do MySQL.
  • Antes de atualizar seus servidores de produção, agora é mais fácil e eficiente usar nosso recurso interno Validar no portal do Azure. Essa ferramenta verifica previamente a compatibilidade do esquema de banco de dados com o MySQL 8.0, destacando possíveis problemas. Embora ofereçamos essa opção prática, recomendamos fortemente que você use a ferramenta oficial de verificação de Upgrade do MySQL da Oracle para testar a compatibilidade do esquema do banco de dados e realizar o teste de regressão necessário para verificar a compatibilidade do aplicativo com os recursos removidos/preteridos na nova versão do MySQL.

    Observação

    Ao usar a ferramenta oficial da Oracle para verificar a compatibilidade do esquema, você pode encontrar alguns avisos que indicam tokens inesperados nos procedimentos armazenados, como: mysql.az_replication_change_master - at line 3,4255: unexpected token 'REPLICATION'mysql.az_add_action_history - PROCEDURE uses obsolete NO_AUTO_CREATE_USER sql_mode Você pode ignorar esses avisos com segurança. Eles se referem aos procedimentos armazenados internos prefixados com mysql., que são usados para dar suporte aos recursos do MySQL do Azure. Esses avisos não afetam a funcionalidade do banco de dados.

  • Dispare o backup sob demanda antes de atualizar para uma versão principal em seu servidor de produção, que pode ser usado para reversão para a versão 5.7 do backup sob demanda completo feito.
  • Antes de prosseguir com a atualização da versão principal, certifique-se de que não há transações XA ativas ou pendentes no banco de dados, pois transações XA em andamento podem potencialmente causar falha no processo de atualização. Para evitar esse problema, primeiro cheque se há transações XA no estado \"preparado\" executando XA RECOVER;. Para qualquer transação identificada, use XA ROLLBACK '{xid}'; para reverter cada transação, substituindo {xid} pela ID da transação. Certifique-se de que todas as transações XA estejam confirmadas ou revertidas antes de iniciar a atualização para manter a consistência da transação e reduzir o risco de falhas na atualização.

Realizar uma atualização de versão principal planejada do MySQL 5.7 para o MySQL 8.0 usando o portal do Azure para servidores com SKUs com Capacidade de Intermitência

Realizar uma atualização de versão principal para um Banco de Dados do Azure para MySQL no nível de computação de SKU com Capacidade de Intermitência requer um fluxo de trabalho especializado. Isso ocorre porque as atualizações de versões principais consomem muitos recursos, exigindo uma quantidade significativa de CPU e memória. As instâncias de SKUs com Capacidade de Intermitência baseadas em crédito podem ter dificuldades com esses requisitos, potencialmente causando falhas no processo de atualização. Portanto, ao fazer atualização de uma SKU com Capacidade de Intermitência, o sistema primeiro faz atualização da camada de computação para uma SKU de Uso Geral para garantir que recursos suficientes estejam disponíveis para a atualização.

Para realizar uma atualização de versão principal para um Banco de Dados do Azure para MySQL no nível de computação de SKU com Capacidade de Intermitência usando o portal do Azure, siga estas etapas:

  1. No portal do Azure, selecione seu servidor existente do Banco de Dados do Azure para MySQL – servidor flexível 5.7.

    Importante

    É recomendável executar a atualização primeiro na cópia restaurada do servidor em vez de atualizar diretamente em produção. Consulte como executar uma restauração pontual.

  2. Na página Visão geral na barra de ferramentas, selecione Atualizar.

    Importante

    Antes de atualizar, acesse o link para obter uma lista dos recursos removidos no MySQL 8.0. Verifique os valores preteridos de sql_mode e remova/desmarque-os do servidor atual do Banco de Dados do Azure para MySQL – servidor flexível 5.7 usando a folha de Parâmetros do Servidor no portal do Azure para evitar falha de implantação. sql_mode com valores NO_AUTO_CREATE_USER, NO_FIELD_OPTIONS, NO_KEY_OPTIONS e NO_TABLE_OPTIONS não têm mais suporte no MySQL 8.0.

    Captura de tela mostrando a Atualização do servidor flexível do Banco de Dados do Azure para MySQL.

  3. Validação de compatibilidade de esquema

    Antes de prosseguir com a atualização, execute a Ferramenta de verificação de atualização do MySQL oficial da Oracle para validar se o esquema do banco de dados atual é compatível com o MySQL 8.0. Essa etapa é fundamental para garantir um processo de atualização tranquilo.

  4. Decisão de pré-atualização

    Antes de prosseguir com a atualização, você precisa escolher a camada de computação para a qual deseja fazer a atualização para executar a atualização da versão principal. Por padrão, o sistema fará a atualização da SKU com Capacidade de Intermitência para a SKU de Uso Geral mais básica, mas você pode optar por fazer atualização para um nível de computação mais alto, se necessário.

    Observação

    Durante a atualização, enquanto seu servidor opera no nível "Uso Geral", você será cobrado apenas pelos recursos reais de "Uso Geral" utilizados durante esse período.

  5. Decisão de pós-atualização

    Decida se deseja manter a SKU de Uso Geral ou reverter para a SKU com Capacidade de Intermitência após a atualização. Essa opção será solicitada durante as etapas iniciais da atualização.

    O sistema atualizará automaticamente sua camada de computação da SKU com Capacidade de Intermitência para a SKU de Uso Geral selecionada, dando suporte à atualização da versão principal.

  6. Atualização da versão principal

    Depois que a camada de computação for atualizada, o sistema iniciará o processo de atualização da versão principal. Monitore o progresso da atualização por meio do portal do Azure. O processo de atualização pode levar algum tempo, dependendo do tamanho e da atividade de seu banco de dados.

    Observação

    Se a atualização da versão principal falhar, a camada de computação não será revertida automaticamente para a SKU com Capacidade de Intermitência anterior. Isso permite que os clientes continuem a atualização da versão principal sem a necessidade de realizar a atualização da camada de computação novamente.

  7. Reversão Automática

    Com base na sua decisão de pré-atualização, o sistema manterá a SKU de Uso Geral ou reverterá automaticamente para a SKU com Capacidade de Intermitência após a conclusão da atualização.

    Observação

    Se você optar por reverter automaticamente para a SKU com Capacidade de Intermitência, o sistema reverterá para a SKU B2S por padrão.

Execute uma atualização de versão principal planejada do MySQL 5.7 para o MySQL 8.0 usando o portal do Azure para servidores de SKUs de Uso Geral e Comercialmente Críticas

Para atualizar a versão principal de um servidor Banco de Dados do Azure para MySQL – servidor flexível 5.7 usando o portal do Azure, execute as etapas a seguir.

  1. No portal do Azure, selecione seu servidor existente do Banco de Dados do Azure para MySQL – servidor flexível 5.7.

    Importante

    É recomendável executar a atualização primeiro na cópia restaurada do servidor em vez de atualizar diretamente em produção. Consulte como executar uma restauração pontual.

  2. Na página Visão geral na barra de ferramentas, selecione Atualizar.

    Importante

    Antes de atualizar, acesse o link para obter uma lista dos recursos removidos no MySQL 8.0. Verifique os valores preteridos de sql_mode e remova/desmarque-os do servidor atual do Banco de Dados do Azure para MySQL – servidor flexível 5.7 usando a folha de Parâmetros do Servidor no portal do Azure para evitar falha de implantação. sql_mode com valores NO_AUTO_CREATE_USER, NO_FIELD_OPTIONS, NO_KEY_OPTIONS e NO_TABLE_OPTIONS não têm mais suporte no MySQL 8.0.

    Captura de tela mostrando a Atualização do servidor flexível do Banco de Dados do Azure para MySQL.

  3. Executar validação pré-atualização

    Antes de prosseguir com a atualização, clique no botão Validar para verificar a compatibilidade do servidor com o MySQL 8.0.

    Captura de tela mostrando a validação.

    Importante

    Ao usar o recurso 'Validar' para verificar o esquema de banco de dados quanto à compatibilidade com o MySQL 8.0, lembre-se de que isso envolve o bloqueio das tabelas para avaliar com precisão todo o esquema. Esse processo pode levar a tempos limite de consulta. Portanto, é aconselhável não executar a validação durante o horário comercial de pico ou quando o banco de dados estiver enfrentando alto tráfego. Escolher um período de baixa atividade para validação pode ajudar a minimizar o impacto em suas operações.

  4. Na barra lateral Atualizar, na caixa de texto Versão do MySQL a ser atualizada, verifique a versão principal do MySQL para a qual você deseja atualizar, ou seja, 8.0.

    Captura de tela que mostra Atualizar.

    Antes de atualizar o servidor primário, primeiro você precisa ter atualizado todos os servidores de réplica de leitura associados. Até que isso seja concluído, a Atualização será desabilitada.

  5. No servidor primário, selecione a mensagem de confirmação para verificar se todos os servidores de réplica foram atualizados e, em seguida, selecione Atualizar.

    Captura de tela que mostra Atualizar.

    Em servidores autônomos e de réplica de leitura, a Atualização é habilitada por padrão.

Executar uma atualização planejada de versão principal do MySQL 5.7 para o MySQL 8.0 usando a CLI do Azure

Para atualizar a versão principal de um servidor do Banco de Dados do Azure– servidor flexível para MySQL 5.7 usando a CLI do Azure, execute as etapas a seguir.

  1. Instale a CLI do Azure para Windows ou use a CLI do Azure no Azure Cloud Shell para executar os comandos de atualização.

    Esta atualização requer a versão 2.40.0 ou posterior da CLI do Azure. Se você está usando o Azure Cloud Shell, a última versão já está instalada. Execute az version para localizar a versão e as bibliotecas dependentes que estão instaladas. Para fazer a atualização para a versão mais recente, execute az upgrade.

  2. Depois de entrar, execute o comando az mysql server upgrade.

    az mysql flexible-server upgrade --name {your mysql server name} --resource-group {your resource group} --subscription {your subscription id} --version 8

  3. No prompt de confirmação, digite y para confirmar ou n para interromper o processo de atualização e, em seguida, pressione Enter.

Executar uma atualização de versão principal do MySQL 5.7 para o MySQL 8.0 no servidor de réplica de leitura usando o portal do Azure

Para atualizar a versão principal de um servidor do Banco de Dados do Azure para MySQL – servidor flexível 5.7 para o MySQL 8.0 em uma réplica de leitura usando o portal do Azure, execute as etapas a seguir.

  1. No portal do Azure, selecione o servidor de réplica de leitura existente do Banco de Dados do Azure para MySQL – servidor flexível 5.7.

  2. Na página Visão geral na barra de ferramentas, selecione Atualizar.

Importante

Antes de atualizar, acesse o link para obter uma lista dos recursos removidos no MySQL 8.0. Verifique os valores preteridos de sql_mode e remova/desmarque-os do servidor atual do Banco de Dados do Azure para MySQL – servidor flexível 5.7 usando a folha de Parâmetros do Servidor no portal do Azure para evitar falha de implantação.

  1. Na seção Atualização, selecione o Atualizar para atualizar uma réplica de leitura do servidor do Banco de Dados do Azure para MySQL – servidor flexível 5.7 para o MySQL 8.0.

    Uma notificação será exibida para confirmar que a atualização foi bem-sucedida.

  2. Na página Visão geral, confirme se a réplica de leitura do servidor do Banco de Dados do Azure para MySQL – servidor flexível está executando a versão 8.0.

  3. Agora vá para o servidor primário e execute a atualização de versão principal nele.

Realize uma atualização de versão principal com tempo de inatividade mínimo do MySQL 5.7 para o MySQL 8.0 usando réplicas de leitura

Para atualizar a versão principal de um servidor do Banco de Dados do Azure para MySQL – servidor flexível 5.7 para o MySQL 8.0 com tempo de inatividade mínimo usando servidores de réplica de leitura, execute as etapas a seguir.

  1. No portal do Azure, selecione seu Banco de Dados do Azure para MySQL – servidor flexível.

  2. Crie uma réplica de leitura do servidor primário.

  3. Atualize a réplica de leitura para a versão 8.0.

  4. Depois de confirmar que o servidor de réplica está executando a versão 8.0, pare o aplicativo de se conectar ao servidor primário.

  5. Verifique o status da replicação para garantir que a réplica tenha alcançado o primário para que todos os dados estejam em sincronia e que nenhuma nova operação esteja sendo executada no primário.

  6. Confirme com o comando Exibir status da réplica no servidor de réplica para exibir o status de replicação.

     SHOW SLAVE STATUS\G

    Se o estado de Slave_IO_Running e Slave_SQL_Running forem yes, e o valor de Seconds_Behind_Master for 0, a replicação está funcionando bem. O valor de Seconds_Behind_Master indica se há atraso da réplica. Se o valor não for 0, a réplica ainda estará processando as atualizações. Após confirmar que o valor de Seconds_Behind_Master é ****, é seguro interromper a replicação.

  7. Promova a réplica de leitura para primária interrompendo a replicação.

  8. Defina o Parâmetro do Servidor read_only como 0 (OFF) para começar a gravar no primário promovido.

  9. Aponte seu aplicativo para a nova primária (réplica antiga) que está executando o servidor 8.0. Cada servidor tem uma cadeia de conexão única. Atualize seu aplicativo para direcionar para a réplica (antiga) em vez da origem.

Observação

Esse cenário só incorre em tempo de inatividade durante as etapas 4 a 7.

Perguntas frequentes

  • Isso causará tempo de inatividade do servidor e, em caso positivo, por quanto tempo?

    Para ter um tempo de inatividade mínimo durante as atualizações, siga as etapas mencionadas em Realize uma atualização de versão principal com tempo de inatividade mínimo do MySQL 5.7 para o MySQL 8.0 usando réplicas de leitura. O servidor ficará indisponível durante o processo de atualização, portanto, recomendamos que execute essa operação durante a janela de manutenção planejada. O tempo de inatividade estimado depende do tamanho do banco de dados, do tamanho do armazenamento provisionado (IOPs provisionados) e do número de tabelas no banco de dados. O tempo de atualização é diretamente proporcional ao número de tabelas no servidor. Para estimar o tempo de inatividade para seu ambiente de servidor, recomendamos primeiro executar a atualização na cópia restaurada do servidor.

  • O que acontece com meus backups após a atualização?

    Todos os backups (automatizados/sob demanda) feitos antes da atualização da versão principal, quando usados para restauração, sempre serão restaurados para um servidor com uma versão mais antiga (5.7). Todos os backups (automatizados/sob demanda) feitos após a atualização da versão principal, serão restaurados para o servidor com a versão atualizada (8.0). É altamente recomendável fazer backup sob demanda antes de executar a atualização da versão principal para facilitar a reversão.

  • No momento, estou usando a SKU com Capacidade de Intermitência. A Microsoft planeja dar suporte à atualização da versão principal para essa SKU no futuro?

    O SKU com capacidade de intermitência não é capaz de dar suporte à atualização de versão principal devido à limitação de desempenho desse SKU.

    Se você precisar realizar uma atualização de versão principal em sua instância do Banco de Dados do Azure para MySQL – servidor flexível e estiver usando atualmente o SKU com capacidade de intermitência, uma solução temporária seria atualizar para a SKU de Uso Geral ou Comercialmente Crítica, executar a atualização e depois voltar para o SKU com Capacidade de Intermitência.

    Observe que a atualização para uma SKU mais alta pode envolver uma alteração nos preços e pode resultar em aumento de custos para sua implantação. No entanto, como não se espera que o processo de atualização demore muito, os custos adicionais não devem ser significativos.

Próximas etapas