Not
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
Viktigt!
Azure SQL Edge dras tillbaka från och med den 30 september 2025. Mer information och migreringsalternativ finns i meddelandet Om pensionering.
Anmärkning
Azure SQL Edge stöder inte längre ARM64-plattformen.
Den här artikeln innehåller information om möjliga fel som uppstår vid distribution och användning av Azure SQL Edge-containrar och innehåller felsökningstekniker som hjälper dig att lösa dessa problem.
Azure SQL Edge har stöd för två distributionsmodeller:
Ansluten distribution via Azure IoT Edge: Azure SQL Edge kan distribueras som en modul för Azure IoT Edge. Mer information finns i Distribuera Azure SQL Edge.
Frånkopplad distribution: Azure SQL Edge-containeravbildningar kan hämtas från Docker Hub och distribueras antingen som en fristående container eller i ett Kubernetes-kluster. Mer information finns i Distribuera Azure SQL Edge med Docker och Distribuera en Azure SQL Edge-container i Kubernetes.
Felsöka IoT Edge-enheter och distributioner
Om du får ett fel när du distribuerar SQL Edge via Azure IoT Edge kontrollerar du att iotedge tjänsten är korrekt konfigurerad och körs. Följande dokument kan vara användbara när du felsöker problem som rör Azure IoT Edge:
Docker-kommandofel
Om du får fel för kommandon docker kontrollerar du att Docker-tjänsten körs och försöker köra med förhöjd behörighet.
I Linux kan du till exempel få följande fel när du kör docker kommandon:
Cannot connect to the Docker daemon. Is the docker daemon running on this host?
Om du får det här felet i Linux kan du prova att köra samma kommandon som föregås av sudo. Om det misslyckas kontrollerar du att Docker-tjänsten körs och startar den om det behövs.
sudo systemctl status docker
sudo systemctl start docker
I Windows kontrollerar du att du startar PowerShell eller kommandotolken som administratör.
Startfel för Azure SQL Edge-container
Om SQL Edge-containern inte kan köras kan du prova följande tester:
Om du använder Azure IoT Edge kontrollerar du att modulavbildningarna har laddats ned och att miljövariablerna och alternativen för att skapa containrar har angetts korrekt i modulmanifestet.
Om du använder Docker- eller Kubernetes-baserad distribution kontrollerar du att
docker runkommandot är korrekt utformat. Mer information finns i Distribuera Azure SQL Edge med Docker och Distribuera en Azure SQL Edge-container i Kubernetes.Om du får ett fel som
failed to create endpoint CONTAINER_NAME on network bridge. Error starting proxy: listen tcp 0.0.0.0:1433 bind: address already in use., försöker du mappa containerporten 1433 till en port som redan används. Detta kan inträffa om du kör SQL Edge lokalt på värddatorn. Det kan också inträffa om du startar två SQL Edge-containrar och försöker mappa dem båda till samma värdport. Om detta inträffar använder du parametern-pför att mappa containerporten 1433 till en annan värdport. Till exempel: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.Om du får ett fel, till exempel
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 deniednär du försöker starta en container, lägger du till användaren i docker-gruppen i Ubuntu. Logga sedan ut och logga in igen eftersom den här ändringen påverkar nya sessioner.usermod -aG docker $USERKontrollera om det finns några felmeddelanden från containern.
docker logs e69e056c702dOm du använder någon programvara för containerhantering kontrollerar du att den stöder containerprocesser som körs som rot. Sqlservr-processen i containern körs som rot.
Som standard körs Azure SQL Edge-containrar som en icke-rotanvändare med namnet
mssql. Om du använder monteringspunkter eller datavolymer för att spara data kontrollerar du attmssqlanvändaren har rätt behörigheter på volymen. Mer information finns i Kör som icke-rotanvändare och Spara data.Om DIN SQL Edge Docker-container avslutas omedelbart efter start kontrollerar du docker-loggarna. Om du använder PowerShell i Windows med
docker runkommandot använder du dubbla citattecken i stället för enkla citattecken. Använd enkla citattecken med PowerShell Core.
SQL Edge-anslutningsfel
Om du inte kan ansluta till SQL Edge-instansen som körs i containern kan du prova följande tester:
Kontrollera att SQL Edge-containern körs genom att titta på
STATUSkolumnen fördocker ps -autdata. Om inte, använddocker start <Container ID>för att starta den.Om du har mappat till en värdport som inte är standard (inte 1433) kontrollerar du att du anger porten i din anslutningssträng. Du kan se portmappningen i
PORTSkolumnen fördocker ps -autdata. Mer information om hur du ansluter till Azure SQL Edge finns i Ansluta och fråga Azure SQL Edge.Om du tidigare distribuerade SQL Edge med en mappad datavolym eller datavolymcontainer och nu använder den befintliga mappade datavolymen eller datavolymcontainern ignorerar SQL Edge värdet för
MSSQL_SA_PASSWORDmiljövariabeln. I stället används det tidigare konfigurerade SA-användarlösenordet. Detta beror på att SQL Edge återanvänder de befintligamasterdatabasfilerna i den mappade volymen eller datavolymcontainern. Om du stöter på det här problemet kan du använda följande alternativ:- Anslut med det tidigare använda lösenordet, om det fortfarande är tillgängligt.
- Konfigurera SQL Edge för att använda en annan mappad volym- eller datavolymcontainer.
- Ta bort de befintliga
masterdatabasfilerna (master.mdfochmastlog.mdf) från den mappade volymen eller datavolymcontainern.
Konfigurations- och felloggar för SQL Edge
Som standard finns SQL Edge-felloggar i katalogen i /var/opt/mssql/log containern och kan nås på något av följande sätt:
Om du monterade en värdkatalog till
/var/opt/mssqlnär du skapade containern kan du i stället titta i underkatalogenlogpå den mappade sökvägen på värden.Genom att använda en interaktiv kommandotolk för att ansluta till containern. Om containern inte körs startar du först containern. Använd sedan en interaktiv kommandotolk för att inspektera loggarna. Du kan hämta container-ID:t genom att köra kommandot
docker ps.docker start <ContainerID> docker exec -it <ContainerID> "/bin/bash"Kör följande kommandon från bash-sessionen i containern:
cd /var/opt/mssql/log cat errorlogOm SQL Edge-containern är igång och du kan ansluta till instansen med hjälp av klientverktyg kan du använda den lagrade proceduren
sp_readerrorlogför att läsa innehållet i SQL Edge-felloggen.
Köra kommandon i en container
Om du har en container som körs kan du köra kommandon i containern från en värdterminal.
Så här kör du container-ID:t:
docker ps -a
Så här startar du en bash-terminal i containerkörningen:
docker exec -it <Container ID> /bin/bash
Nu kan du köra kommandon som om du kör dem i terminalen i containern. När du är klar skriver du exit. Detta avslutas i den interaktiva kommandosessionen, men containern fortsätter att köras.
Aktivera utförlig loggning
Om standardloggnivån för strömningsmotorn inte ger tillräckligt med information kan felsökningsloggning för strömningsmotorn aktiveras i SQL Edge. Om du vill aktivera felsökningsloggning lägger du till RuntimeLogLevel=debug miljövariabeln i SQL Edge-distributionen. När du har aktiverat felsökningsloggning försöker du återskapa problemet och kontrollerar om det finns relevanta meddelanden eller undantag i loggarna.
Anmärkning
Alternativet Utförlig loggning bör endast användas för felsökning och inte för vanlig produktionsarbetsbelastning.