Como atualizar o Clusters de Big Data do SQL Server

Aplica-se a: SQL Server 2019 (15.x)

Importante

O complemento Clusters de Big Data do Microsoft SQL Server 2019 será desativado. O suporte para Clusters de Big Data do SQL Server 2019 será encerrado em 28 de fevereiro de 2025. Todos os usuários existentes do SQL Server 2019 com Software Assurance terão suporte total na plataforma e o software continuará a ser mantido por meio de atualizações cumulativas do SQL Server até esse momento. Para obter mais informações, confira a postagem no blog de anúncio e as opções de Big Data na plataforma do Microsoft SQL Server.

O caminho de atualização depende da versão atual do Cluster de Big Data do SQL Server. A atualização de uma versão com suporte, incluindo a GDR (versão de distribuição geral), CU (atualização cumulativa) ou atualização de QFE (Quick Fix Engineering), pode ser feita no local. Não há suporte para a atualização in-loco de um CTP (Community Technology Preview) ou da versão Release Candidate do BDC. Você precisa remover e recriar o cluster. As seguintes seções descrevem as etapas de cada cenário:

• Atualização a partir da versão com suporte
• Atualizar uma implantação BDC do CTP ou da versão Release Candidate

Observação

A versão mais antiga com suporte de Clusters de Big Data é o SQL Server 2019 CU8.

Notas sobre a versão da atualização

Antes de continuar, confira as notas sobre a versão da atualização para ver os problemas conhecidos.

Aviso

O parâmetro imagePullPolicy era necessário para ser definido como no arquivo control.json do perfil de implantação "Always" quando o cluster foi implantado inicialmente. Esse parâmetro não pode ser alterado após a implantação. Caso seja definido com um valor diferente, resultados inesperados poderão ocorrer durante o processo de atualização e uma reimplantação de cluster será necessária.

Atualização a partir da versão com suporte

Esta seção explica como atualizar um BDC do SQL Server de uma versão com suporte (do SQL Server 2019 GDR1 em diante) para uma versão mais recente com suporte.

1. Verifique se não há sessões ativas do Livy.

   Garanta que nenhuma sessão ativa ou trabalhos em lotes do Livy estejam em execução no Azure Data Studio. Uma maneira fácil de confirmar isso é por meio do comando curl ou de um navegador para solicitar estas URLs:

   • <your-gateway-endpoint>/gateway/default/livy/v1/sessions
   • <your-gateway-endpoint>/gateway/default/livy/v1/batches

2. Faça backup da instância mestra do SQL Server.

3. Faça backup do HDFS.

   azdata bdc hdfs cp --from-path <path> --to-path <path>
   

   Por exemplo:

   azdata bdc hdfs cp --from-path hdfs://user/hive/warehouse/%%D --to-path ./%%D
   

4. Atualizar CLI de Dados do Azure (azdata).

   Siga as instruções para instalar o CLI de Dados do Azure (azdata).

   • Windows Installer
   • Linux com apt
   • Linux com yum
   • Linux com zypper

   Observação

   Se CLI de Dados do Azure (azdata) tiver sido instalado com pip, você precisará removê-lo manualmente antes da instalação com o Windows Installer ou o gerenciador de pacotes do Linux.

5. Atualize o Cluster de Big Data.

   azdata bdc upgrade -n <clusterName> -t <imageTag> -r <containerRegistry>/<containerRepository>
   

   Por exemplo, o script a seguir usa a marca de imagem 2019-CU19-ubuntu-20.04:

   azdata bdc upgrade -n bdc -t 2019-CU19-ubuntu-20.04 -r mcr.microsoft.com/mssql/bdc
   

Observação

As marcas de imagem mais recentes estão disponíveis nas Notas sobre a versão dos Clusters de Big Data do SQL Server 2019.

Importante

Se usar um repositório privado para extrair previamente as imagens para implantar ou atualizar o BDC, verifique se as imagens de build atuais e as imagens de build de >destino estão no repositório privado. Isso permitirá a reversão bem-sucedida, caso ela seja necessária. Além disso, se você tiver alterado as >credenciais do repositório privado depois da implantação original, atualize as variáveis de ambiente DOCKER_PASSWORD e >DOCKER_USERNAME correspondentes. Não há suporte para a atualização usando diferentes repositórios privados para builds atuais e de destino.

Aumentar o tempo limite para a atualização

Um tempo limite poderá acontecer se determinados componentes não forem atualizados no tempo alocado. O seguinte exemplo de código mostra como poderia ser a falha:

>azdata.EXE bdc upgrade --name <mssql-cluster>
Upgrading cluster to version 15.0.4003

NOTE: Cluster upgrade can take a significant amount of time depending on
configuration, network speed, and the number of nodes in the cluster.

Upgrading Control Plane.
Control plane upgrade failed. Failed to upgrade controller.

Para aumentar os tempos limite de uma atualização, use os parâmetros --controller-timeout e --component-timeout para especificar valores maiores ao emitir a atualização. Essa opção está disponível apenas da versão SQL Server 2019 CU2 em diante. Por exemplo:

azdata bdc upgrade -t 2019-CU19-ubuntu-20.04 --controller-timeout=40 --component-timeout=40 --stability-threshold=3

O --controller-timeout designa o número de minutos que você deverá aguardar para que o controlador ou o banco de dados do controlador conclua a atualização. --component-timeout designa a quantidade de tempo em que cada fase subsequente da atualização precisa ser concluída.

Para aumentar os tempos limite de uma atualização antes da versão CU19 do SQL Server 2019, edite o mapa de configuração de atualização. Para editar o mapa de configuração da atualização:

Execute o comando a seguir:

kubectl edit configmap controller-upgrade-configmap

Edite os seguintes campos:

controllerUpgradeTimeoutInMinutes designa o número de minutos que deverão ser aguardados para que o controlador ou o banco de dados do controlador conclua a atualização. O padrão é 5. Atualize para pelo menos 20. totalUpgradeTimeoutInMinutes: designa a quantidade combinada de tempo em que o controlador e o banco de dados do controlador concluem a atualização (atualização do controlador + banco de dados do controlador). O padrão é 10. Atualize para pelo menos 40. componentUpgradeTimeoutInMinutes: designa a quantidade de tempo em que cada fase subsequente da atualização precisa ser concluída. O padrão é 30. Atualize para 45.

Salve e saia.

Atualizar uma implantação BDC do CTP ou da versão Release Candidate

Não há suporte para uma atualização in-loco de uma CTP ou da versão Release Candidate dos Clusters de Big Data do SQL Server. A seção a seguir explica como remover e recriar o cluster manualmente.

Fazer backup e excluir o cluster antigo

Não há atualização in-loco para clusters de Big Data implantados antes do SQL Server 2019 GDR1. A única maneira de atualizar para uma nova versão é remover o cluster manualmente e recriá-lo. Cada versão tem uma versão exclusiva do CLI de Dados do Azure (azdata) que não é compatível com a versão anterior. Além disso, se uma imagem de contêiner for baixada em um cluster implantado com outra versão mais antiga, a imagem mais recente poderá não ser compatível com as imagens mais antigas no cluster. A imagem mais nova será capturada se você estiver usando a marca de imagem latest no arquivo de configuração de implantação nas configurações do contêiner. Por padrão, cada versão tem uma tag de imagem específica correspondente à versão de lançamento do SQL Server. Para fazer a atualização para a última versão, use as seguintes etapas:

1. Antes de excluir o cluster antigo, faça backup dos dados na instância mestra do SQL Server e no HDFS. Para a instância mestra do SQL Server, você poderá usar Backup e restauração do SQL Server. Para o HDFS, você pode copiar os dados com o curl.

2. Exclua o cluster antigo com o comando azdata delete cluster.

    azdata bdc delete --name <old-cluster-name>
   

   Importante

   Use a versão do CLI de Dados do Azure (azdata) que corresponde ao cluster. Não exclua um cluster mais antigo com a versão mais recente do CLI de Dados do Azure (azdata).

   Observação

   A emissão de um comando azdata bdc delete resultará em todos os objetos criados dentro do namespace identificado com o nome do cluster de Big Data serem excluídos, mas não o próprio namespace. O namespace pode ser reutilizado para implantações subsequentes, desde que esteja vazio e nenhum outro aplicativo tenha sido criado dentro dele.

3. Desinstale a versão antiga do CLI de Dados do Azure (azdata).

   pip3 uninstall -r https://azdatacli.blob.core.windows.net/python/azdata/2019-rc1/requirements.txt
   

4. Instalar a versão mais recente do CLI de Dados do Azure (azdata). Os comandos a seguir instalam CLI de Dados do Azure (azdata) da versão mais recente:

   Windows:

   pip3 install -r https://aka.ms/azdata
   

   Linux:

   pip3 install -r https://aka.ms/azdata --user
   

   Importante

   Em cada caso, o caminho para a versão n-1 da CLI de Dados do Azure (azdata) muda. Mesmo que você tenha instalado o CLI de Dados do Azure (azdata) anteriormente, precisará reinstalar com base no caminho mais recente antes de criar o cluster.

Verificar a versão do azdata

Antes de implantar um novo cluster de Big Data, verifique se você está usando a última versão do CLI de Dados do Azure (azdata) com o parâmetro --version:

azdata --version

Instalar a nova versão

Depois de remover o cluster de Big Data anterior e instalar o CLI de Dados do Azure (azdata) mais recente, implante o novo cluster de Big Data usando as instruções de implantação atuais. Para obter mais informações, confira Como implantar Clusters de Big Data do SQL Server no Kubernetes. Em seguida, restaure os bancos de dados ou os arquivos necessários.

Próximas etapas

Para obter mais informações sobre clusters de Big Data, confira O que são Clusters de Big Data do SQL Server.