Устранение неполадок с развертываниями SQL Azure Для пограничных вычислений

  • Статья

Важно!

Azure SQL Edge больше не поддерживает платформу ARM64.

В этой статье содержится информация о возможных ошибках, возникающих при развертывании и использовании контейнеров Azure SQL Edge, а также методы устранения неполадок, помогающие решить эти проблемы.

Azure SQL Edge поддерживает две модели развертывания:

Устранение неполадок устройств и развертываний IoT Edge

Если вы получаете сообщение об ошибке при развертывании SQL Edge через Azure IoT Edge, убедитесь, что служба iotedge правильно настроена и работает. Следующие документы могут быть полезны при устранении неполадок, связанных с Azure IoT Edge:

Ошибки команды Docker

Если возникают ошибки для любых docker команд, убедитесь, что служба Docker запущена, и попробуйте выполнить с повышенными правами.

Например, при выполнении команд docker в Linux вы можете получить следующее сообщение об ошибке:

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

Если вы получаете эту ошибку в Linux, попробуйте выполнить те же команды с префиксом sudo. Если это не удается, убедитесь, что служба Docker запущена, и запустите ее при необходимости.

sudo systemctl status docker
sudo systemctl start docker

В Windows убедитесь, что запускаете PowerShell или командную строку от имени администратора.

Ошибки запуска контейнера Azure SQL Edge

Если контейнер SQL Edge не запускается, попробуйте следующие тесты.

  • Если вы используете Azure IoT Edge, убедитесь, что образы модулей были загружены успешно, и что переменные среды и параметры создания контейнеров правильно указаны в манифесте модуля.

  • Если вы используете развертывание на основе Docker или Kubernetes, убедитесь, что команда правильно сформирована docker run . Дополнительные сведения см. в статьях Развертывание SQL Azure для пограничных вычислений с помощью Docker и Развертывание контейнера SQL Azure для пограничных вычислений в Kubernetes.

  • Если возникает ошибка, такая как failed to create endpoint CONTAINER_NAME on network bridge. Error starting proxy: listen tcp 0.0.0.0:1433 bind: address already in use., вы пытаетесь сопоставить порт контейнера 1433 с уже используемым портом. Это может произойти, если вы используете SQL Edge локально на хост-машине. Это также может произойти, если вы запустите два контейнера SQL Edge и попытаетесь сопоставить их оба с одним и тем же портом хоста. В этом случае используйте параметр -p, чтобы сопоставить порт контейнера 1433 с другим портом узла. Например:

    sudo docker run --cap-add SYS_PTRACE -e 'ACCEPT_EULA=1' -e 'MSSQL_SA_PASSWORD=yourStrong(!)Password' -p 1433:1433 --name azuresqledge -d mcr.microsoft.com/azure-sql-edge-developer.

  • Если при попытке запуска контейнера возникает ошибка 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, добавьте пользователя в группу docker в Ubuntu. Затем выйдите и войдите снова, так как это изменение влияет на новые сеансы.

    usermod -aG docker $USER

  • Проверьте наличие сообщений об ошибках от контейнера.

    docker logs e69e056c702d

  • Если вы используете программное обеспечение для управления контейнером, убедитесь, что оно поддерживает привилегированное выполнение процессов контейнера. Процесс sqlservr в контейнере выполняется в привилегированном режиме.

  • По умолчанию контейнеры Azure SQL Edge запускаются от имени пользователя без корневых полномочий с именем mssql. Если вы используете точки подключения или тома данных для сохранения данных, убедитесь, что mssql у пользователя есть соответствующие разрешения на том. Дополнительные сведения см. в разделе Запуск от имени пользователя, не являющегося корневым, и Сохранение данных.

  • Если ваш контейнер SQL Edge Docker закрывается сразу после запуска, проверьте журналы Docker. Если вы используете PowerShell в Windows с помощью команды docker run, используйте двойные кавычки вместо одинарных. В PowerShell Core используйте одинарные кавычки.

  • Просмотрите Журналы ошибок SQL Edge.

Сбои подключения к SQL Edge

Если вы не можете подключиться к экземпляру SQL Edge, запущенному в вашем контейнере, попробуйте следующие тесты:

  • Убедитесь, что контейнер SQL Edge запущен, просматривая STATUS столбец выходных docker ps -a данных. При необходимости запустите его с помощью команды docker start <Container ID>.

  • Если вы сопоставляете с портом, отличным от порта узла по умолчанию (1433), обязательно укажите этот порт в строке подключения. Сопоставление портов можно увидеть в столбце PORTSdocker ps -a выходных данных. Дополнительные сведения о подключении к Azure SQL Edge см. в Подключение и запросе Azure SQL Edge.

  • Если вы ранее развернули SQL Edge с сопоставленным томом данных или контейнером тома данных, а теперь используйте существующий сопоставленный том данных или контейнер тома данных, SQL Edge игнорирует значение переменной MSSQL_SA_PASSWORD среды. Вместо этого используется ранее настроенный пароль пользователя SA. Это происходит, так как SQL Edge повторно использует существующие master файлы баз данных в сопоставленном томе или контейнере тома данных. Если вы столкнулись с этой проблемой, вы можете использовать следующие варианты:

    • Подключитесь, используя ранее использованный пароль, если он еще доступен.
    • Настройте SQL Edge для использования другого сопоставленного тома или контейнера тома данных.
    • Удалите существующие master файлы базы данных (master.mdf и mastlog.mdf) из сопоставленного тома или контейнера тома данных.

  • Просмотрите Журналы ошибок SQL Edge.

Журналы установки и ошибок SQL Edge

По умолчанию журналы ошибок SQL Edge присутствуют в /var/opt/mssql/log каталоге в контейнере и могут быть доступны с помощью любого из следующих способов:

  • Если вы подключили каталог /var/opt/mssql узла к созданию контейнера, вместо этого можно просмотреть log подкаталог на сопоставленном пути на узле.

  • Используя интерактивную командную строку для подключения к контейнеру. Если контейнер не запущен, сначала запустите его. Затем проверьте журналы с помощью интерактивной командной строки. Идентификатор контейнера можно получить, выполнив команду docker ps.

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

    Из сеанса Bash внутри контейнера выполните следующие команды:

    cd /var/opt/mssql/log
cat errorlog

  • Если контейнер SQL Edge запущен и запущен, и вы можете подключиться к экземпляру с помощью клиентских средств, можно использовать хранимую процедуру sp_readerrorlog для чтения содержимого журнала ошибок SQL Edge.

Выполнение команд в контейнере

Вы можете выполнять команды из работающего контейнера с помощью терминала узла.

Чтобы получить идентификатор контейнера, выполните следующую команду:

docker ps -a

Чтобы запустить терминал Bash в контейнере, выполните следующую команду:

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

Теперь вы можете выполнять команды так, выполняли бы их из терминала внутри контейнера. По завершении введите exit. В этом случае завершается интерактивный сеанс команд, однако контейнер продолжает работать.

Включение ведения подробного журнала

Если уровень журнала по умолчанию для подсистемы потоковой передачи не предоставляет достаточно сведений, ведение журнала отладки для подсистемы потоковой передачи можно включить в SQL Edge. Чтобы включить ведение журнала отладки, добавьте RuntimeLogLevel=debug переменную среды в развертывание SQL Edge. После включения ведения журнала отладки попытайтесь воспроизвести проблему и проверьте журналы на наличие соответствующих сообщений или исключений.

Примечание.

Параметр "Подробное ведение журнала" следует использовать только для устранения неполадок, а не для обычной производственной нагрузки.

Следующие шаги