Compartilhar via

Solucionar problemas de implantações do SQL do Azure no Edge

  • Artigo

Importante

O SQL do Azure no Edge será desativado em 30 de setembro de 2025. Para obter mais informações e opções de migração, veja o Aviso de aposentadoria.

Observação

O SQL do Azure no Edge encerrou o suporte à plataforma ARM64.

Este artigo fornece informações sobre possíveis erros ao implantar e usar contêineres do SQL do Azure no Edge e fornece técnicas de solução de problemas para ajudar a resolver esses problemas.

O SQL do Azure no Edge dá suporte a dois modelos de implantação:

Solucionar problemas de dispositivos e implantações IoT Edge

Se você receber um erro ao implantar o SQL no Edge por meio do Azure IoT Edge, verifique se o serviço iotedge está configurado corretamente e em execução. Os documentos a seguir podem ser úteis ao solucionar problemas relacionados ao Azure IoT Edge:

Erros de comando do Docker

Se você receber erros em algum comando docker, certifique-se de que o serviço Docker esteja em execução e tente executar com permissões elevadas.

Por exemplo, no Linux, você pode receber o seguinte erro ao executar comandos docker:

Cannot connect to the Docker daemon. Is the docker daemon running on this host?

Se você receber esse erro no Linux, tente executar os mesmos comandos precedidos com sudo. Se isso falhar, verifique se o serviço Docker está em execução e inicie-o, se necessário.

sudo systemctl status docker
sudo systemctl start docker

No Windows, verifique se você está iniciando o PowerShell ou o prompt de comando como Administrador.

Erros de inicialização do contêiner do SQL do Azure no Edge

Se o contêiner do SQL no Edge não for executado, tente os seguintes testes:

  • Se estiver a utilizar o Azure IoT Edge, certifique-se de que as imagens do módulo foram descarregadas com sucesso e que as variáveis ​​ambientais e as opções de criação de contêiner estão corretamente especificadas no manifesto do módulo.

  • Se você estiver usando implantação baseada em Docker ou Kubernetes, certifique-se de que o comando docker run esteja formado corretamente. Para obter mais informações, confira Implantar o SQL do Azure no Edge usando o Docker e Implantar um contêiner do SQL do Azure no Edge no Kubernetes.

  • Se você receber um erro como failed to create endpoint CONTAINER_NAME on network bridge. Error starting proxy: listen tcp 0.0.0.0:1433 bind: address already in use., isso indicará que você está tentando mapear a porta de contêiner 1433 para uma porta que já está em uso. Isso poderá acontecer se você estiver executando o SQL no Edge localmente no computador host. Isso também poderá acontecer se você iniciar dois contêineres de SQL no Edge e tentar mapeá-los para a mesma porta de host. Se isso acontecer, use o parâmetro -p para mapear a porta de contêiner 1433 para uma porta de host diferente. Por exemplo:

    sudo docker run --cap-add SYS_PTRACE -e 'ACCEPT_EULA=1' -e 'MSSQL_SA_PASSWORD=<password>' -p 1433:1433 --name azuresqledge -d mcr.microsoft.com/azure-sql-edge-developer.

  • Se você receber um erro como Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Get http://%2Fvar%2Frun%2Fdocker.sock/v1.30tdout=1&tail=all: dial unix /var/run/docker.sock: connect: permission denied ao tentar iniciar um contêiner, adicione o usuário ao grupo do Docker no Ubuntu. Em seguida, saia e faça login novamente, pois essa alteração afeta novas sessões.

    usermod -aG docker $USER

  • Verifique se há alguma mensagem de erro do contêiner.

    docker logs e69e056c702d

  • Se você estiver usando qualquer software de gerenciamento de contêiner, verifique se ele dá suporte a processos de contêiner em execução como raiz. O processo sqlservr no contêiner é executado como raiz.

  • Por padrão, os contêineres do SQL do Azure no Edge são executados como um usuário não raiz chamado mssql. Se você estiver usando pontos de montagem ou volumes de dados para persistir dados, certifique-se de que o usuário mssql tenha permissões apropriadas no volume. Para obter mais informações, confira Executar como usuário não raiz e Manter dados.

  • Se o contêiner do SQL no Edge no Docker for encerrado imediatamente após a inicialização, verifique os logs do Docker. Se você estiver usando o PowerShell no Windows com o comando docker run, use aspas duplas em vez de aspas simples. Com o PowerShell Core, use aspas simples.

  • Examine os logs de erros do SQL no Edge.

Falhas de conexão do SQL no Edge

Se você não conseguir conectar-se à instância do SQL no Edge em execução no seu contêiner, tente os seguintes testes:

  • Certifique-se de que seu contêiner SQL do Azure no Edge esteja em execução, observando a coluna STATUS da saída docker ps -a. Caso contrário, use docker start <Container ID> para iniciá-lo.

  • Se você mapeou para uma porta de host não padrão (diferente de 1433), verifique se está especificando a porta na cadeia de conexão. Você pode ver o mapeamento da porta na coluna PORTS da saída docker ps -a. Para obter mais informações sobre como se conectar ao SQL do Azure no Edge, veja Conectar e consultar o SQL do Azure no Edge.

  • Se você implantou anteriormente o SQL do Azure no Edge com um volume de dados mapeado ou contêiner de volume de dados e agora usa o volume de dados mapeado ou contêiner de volume de dados existente, o SQL do Azure no Edge ignora o valor da variável de ambiente MSSQL_SA_PASSWORD. Em vez disso, a senha de usuário SA configurada anteriormente é usada. Isso acontece porque o SQL do Azure no Edge reutiliza os arquivos de bancos de dados master existentes no volume mapeado ou no contêiner de volume de dados. Se você encontrar esse problema, poderá usar as seguintes opções:

    • Conecte-se usando a senha usada anteriormente, se ainda estiver disponível.
    • Configure o SQL no Edge para usar um volume mapeado ou um contêiner de volume de dados diferente.
    • Remova os arquivos de banco de dados master existentes (master.mdf e mastlog.mdf) do volume mapeado ou do contêiner de volume de dados.

  • Examine os logs de erros do SQL no Edge.

Configuração do SQL do Azure no Edge e logs de erros

Por padrão, os logs de erros do SQL do Azure no Edge estão presentes no diretório /var/opt/mssql/log dentro do contêiner e podem ser acessados ​​de qualquer uma das seguintes maneiras:

  • Se você montou um diretório de host em /var/opt/mssql quando criou seu contêiner, poderá procurar no subdiretório log no caminho mapeado no host.

  • Usando um prompt de comando interativo para se conectar ao contêiner. Se o contêiner não estiver em execução, primeiro inicie-o. Em seguida, use um prompt de comando interativo para inspecionar os logs. Obtenha a ID do contêiner executando o comando docker ps.

    docker start <ContainerID>
docker exec -it <ContainerID> "/bin/bash"

    Na sessão de Bash dentro de seu contêiner, execute os seguintes comandos:

    cd /var/opt/mssql/log
cat errorlog

  • Se o contêiner do SQL do Azure no Edge estiver instalado e em execução e você conseguir se conectar à instância usando ferramentas cliente, poderá usar o procedimento armazenado sp_readerrorlog para ler o conteúdo do log de erros do SQL do Azure no Edge.

Executar comandos em um contêiner

Se você tiver um contêiner em execução, poderá executar comandos dentro do contêiner de um terminal de host.

Para obter a ID do contêiner, execute:

docker ps -a

Para iniciar um terminal de Bash na execução do contêiner:

docker exec -it <Container ID> /bin/bash

Agora você pode executar comandos como se estivesse executando-os no terminal dentro do contêiner. Quando terminar, digite exit. Isso é encerrado na sessão de comando interativo, mas o contêiner continua a ser executado.

Habilitar registro em log detalhado

Se o nível de log padrão do mecanismo de streaming não fornecer informações suficientes, o log de depuração do mecanismo de streaming poderá ser habilitado no SQL do Azure no Edge. Para habilitar o log de depuração, adicione a variável de ambiente RuntimeLogLevel=debug à implantação do SQL do Azure no Edge. Depois de habilitar o log de depuração, tente repetir o problema e verifique os logs quanto a mensagens ou exceções relevantes.

Observação

A opção de registro detalhado em log somente deve ser usada para solucionar problemas e não para a carga de trabalho de produção regular.

Conteúdo relacionado