A go-mssqldb használata az Azure SQL Database szolgáltatással

A go-mssqldb meghajtó támogatja az Azure SQL Database, Azure SQL Managed Instance és SQL adatbázis csatlakozását a Microsoft Fabric-ben. Ez a cikk az Azure-specifikus konfigurációt, hitelesítést, kapcsolati korlátokat és hibakeresést tárgyal, amelyek eltérnek az on-premises SQL Server-től.

Csatlakozás az Azure SQL Database-hez

Azure SQL Database alapértelmezés szerint titkosított kapcsolatokat igényel. Határozd encrypt=true meg és TrustServerCertificate=false egyértelműen úgy, hogy a kapcsolat TLS-t használjon, és érvényesítse a szerver tanúsítványt:

db, err := sql.Open("sqlserver",
    "sqlserver://<user>:<password>@<server>.database.windows.net?database=<database>&encrypt=true&TrustServerCertificate=false")
if err != nil {
    panic(err)
}

Megjegyzés:

Ha kihagyod encrypt, az illesztőprogram nem ad automatikusan hozzá Azure-specifikus TLS beállításokat. Tartsa meg a(z) encrypt=true&TrustServerCertificate=false elemet az Azure SQL kapcsolati sztringekben.

Jelszó nélküli hitelesítés használata (ajánlott)

Microsoft Entra ID hitelesítés megszünteti a jelszavakat a kapcsolati láncsorokból. ActiveDirectoryDefault automatikusan kiválasztja a környezet legjobb elérhető hitelesítését, ami kényelmessé teszi a fejlesztést:

import (
    "database/sql"
    "log"

    _ "github.com/microsoft/go-mssqldb/azuread"
)

func main() {
    db, err := sql.Open("azuresql",
        "sqlserver://<server>.database.windows.net?database=<database>&fedauth=ActiveDirectoryDefault&encrypt=true&TrustServerCertificate=false")
    if err != nil {
        log.Fatal(err)
    }
    defer db.Close()
}

Important

ActiveDirectoryDefault fejlesztéshez kényelmes, de hozzáadhat a kapcsolati késleltetést, mivel több hitelesítési forrást is vizsgál. Termelési szolgáltatásokhoz inkább egy explicit módszert válasszunk, mint ActiveDirectoryManagedIdentity például vagy ActiveDirectoryServicePrincipal.

Hogyan oldja meg az ActiveDirectoryDefault az igazolványokat

ActiveDirectoryDefault A következő hitelesítési forrásokat sorrendben próbálja ki, és az elsőt használja:

Order	Hitelesítési forrás	Tipikus környezet
1	Környezeti változók (AZURE_CLIENT_ID, AZURE_TENANT_ID, AZURE_CLIENT_SECRET)	CI/CD-folyamatok, Docker konténerek
2	Munkaterhelés-azonosság	Kubernetes-podok Azure Workload Identityvel
3	Felügyelt identitás	Azure VMs, App Service, Container Apps, Azure Functions
4	Azure CLI (az login)	Helyi fejlesztés
5	Azure fejlesztői parancssori felület (azd auth login)	Helyi fejlesztés

Ez a hitelesítési lánc kényelmessé teszi a ActiveDirectoryDefault használatát a fejlesztés során, de az egymás utáni próbálkozások minden új kapcsolat késleltetését növelik. Gyártáshoz határozd meg a pontos hitelesítési módszert (például ActiveDirectoryManagedIdentity), hogy az illesztőprogram kihagyja a felesleges ellenőrzéseket.

Menedzselt identitás a termeléshez (ajánlott)

Az Azure-ban hosztolt alkalmazásoknak (App Service, Container Apps, Azure Functions vagy Azure VM-ek) menedzselt identitást kell használniuk, amely explicit fedauth értékkel rendelkezik. Ez a megközelítés elkerüli a hitelesítési lánc túlterhelését, és megszünteti a környezeti változóktól vagy a CLI állapottól való függőséget.

Rendszer által hozzárendelt felügyelt identitás:

sqlserver://<server>.database.windows.net?database=<database>&fedauth=ActiveDirectoryManagedIdentity&encrypt=true&TrustServerCertificate=false

Felhasználó által hozzárendelt menedzselt identitás (megadja az ügyfélazonosítót):

sqlserver://<server>.database.windows.net?database=<database>&fedauth=ActiveDirectoryManagedIdentity&user id=<client-id>&encrypt=true&TrustServerCertificate=false

Biztosíts az identitáshoz hozzáférést az adatbázisban

Miután konfigurálta a felügyelt identitást az Azure-erőforráson, hozzon létre egy különálló adatbázis-felhasználót:

CREATE USER [my-app-identity] FROM EXTERNAL PROVIDER;
ALTER ROLE db_datareader ADD MEMBER [my-app-identity];
ALTER ROLE db_datawriter ADD MEMBER [my-app-identity];

Rendszerhez rendelt identitásokhoz használjuk az Azure erőforrás nevét. A felhasználó által hozzárendelt identitásokhoz az identitásnevet használjuk.

Szolgáltatás fő az automatizáláshoz

CI/CD vezetékek vagy szolgáltatás-szolgáltatás hitelesítés esetén:

sqlserver://<server>.database.windows.net?database=<database>&fedauth=ActiveDirectoryServicePrincipal&user id=<client-id>&password=<client-secret>&encrypt=true&TrustServerCertificate=false

Minden hitelesítési típusért lásd: Microsoft Entra ID hitelesítés.

Az Azure tűzfal konfigurálása

Azure SQL Database szerver szintű tűzfalat használ. Engedélyezned kell az ügyfél nyilvános IP-címét, vagy privát végpontot kell használnod.

Hiba: Nem lehet szervert nyitni

Ez a hibaüzenet azt jelzi, hogy az Azure tűzfal blokkolja az ügyfél IP-címedet:

mssql: login error: Cannot open server '<server>' requested by the login.
Client with IP address '<client-ip>' is not allowed to access the server.

Megoldások:

1. Tűzfal szabály hozzáadása az Azure portálba: SQL szerver>Hálózat>Tűzfal szabály hozzáadása tűzfal szabály.
2. Ha az alkalmazása az Azure-ban fut, kapcsolja be a „Az Azure-szolgáltatások és -erőforrások hozzáférhetnek ehhez a kiszolgálóhoz” beállítást.
3. Privát kapcsolathoz állíts be egy privát végpontot.

Hiba: A kapcsolat időlejárt

Ha a kapcsolat időlejár egyértelmű hiba nélkül, a tűzfal valószínűleg némán blokkolja a kapcsolatot. Először ellenőrizd a tűzfal szabályait.

Kapcsolati korlátok szolgáltatási szint szerint

Azure SQL Database a szolgáltatási szint alapján érvényesíti a kapcsolati korlátokat adatbázisonként. A határ túllépése hitelesítési hibákat okoz új kapcsolatoknál. A teljes korláttáblázatokat lásd: DTU-alapú önálló adatbázis erőforrás-korlátai és vCore-alapú önálló adatbázis erőforrás-korlátai.

Állítsd be a MaxOpenConns-t a szintedhez

Mindig állítsd MaxOpenConns be az értéket az Azure SQL tier kapcsolati korlátja alatt:

// Example for S2 tier (60 max workers).
// Leave headroom for Azure management connections and other clients.
db.SetMaxOpenConns(20)
db.SetMaxIdleConns(10)
db.SetConnMaxLifetime(5 * time.Minute)

Tip

Ha több alkalmazás ugyanazon az adatbázison osztozik, oszd el a kapcsolati korlátot az összes alkalmazás között. Például, ha három szolgáltatás oszt meg egy S2 adatbázist (maximum 60 dolgozó), akkor 15-20 kapcsolatot osztanak ki szolgáltatásonként.

Az Azure SQL korlátozásának kezelése

Az Azure SQL Database képes korlátozni a kapcsolatokat és lekérdezéseket, amikor az adatbázis közelíti az erőforrás-korlátokat (CPU, IO, memória vagy munkamenetszám). A korlátozás bizonyos hibakódok formájában jelentkezik.

Gyakori korlátozási hibák

Hiba száma	Üzenetminta	A probléma oka
10928	Resource ID: %d. The %s limit for the database is %d and has been reached.	Elérve a munkamenet vagy munkavégzési határt.
10929	Resource ID: %d. The %s minimum guarantee is %d, maximum limit is %d.	Az erőforrás-szabályozó korlátozása.
40501	The service is currently busy.	Általános korlátozás. Próbálkozzon újra.
40544	The database has reached its size quota.	Elérve az adatbázis méretkorlátját. Növeld a kapacitást vagy a szabad helyet, mielőtt újra próbálkoznál.
40549	Session is terminated because you have a long-running transaction.	A tranzakció túllépte az időkorlátot.
40550	Session is terminated because of too many locks.	Túlzott zár megszerzés.
40551	Session is terminated because of excessive tempdb usage.	Túlzott tempdb használat.
40552	Session is terminated because of excessive transaction log usage.	A tranzakciós napló területe kimerült.
40553	Session is terminated because of excessive memory usage.	Túlzott memóriafogyasztás.
40613	Database '%.*ls' on server '%.*ls' is not currently available.	Az adatbázis áthelyezése vagy újrakonfigurálása.
49918	Cannot process request. Not enough resources to process request.	Erőforrás-kimerültség.
49919	Cannot process create or update request.	Túl sok egyidejű létrehozás/frissítési művelet.
49920	Cannot process request. Too many operations in progress.	A párhuzamos működési határ elérve.

A korlátozott kérelmek újrapróbálása

Az előző táblázatban található Azure SQL korlátozási és elérhetőségi hiba többsége átmeneti, és exponenciális visszalépéssel kell újra próbálkozni. A hiba 40544 nem múlékony. Ez azt jelenti, hogy az adatbázis elérte a méretkvótáját, így a művelet csak akkor fog sikeres legyen, ha felskálázódsz vagy nem törlöd az adatokat.

A teljes újrapróbálkozás megvalósításához lásd: Hibakezelés és újrapróbálkozási minták.

import (
    "errors"

    mssql "github.com/microsoft/go-mssqldb"
)

func isAzureThrottling(err error) bool {
    var mssqlErr mssql.Error
    if !errors.As(err, &mssqlErr) {
        return false
    }
    switch mssqlErr.Number {
    case 10928, 10929, 40501, 40549, 40550, 40551, 40552, 40553,
        40613, 49918, 49919, 49920:
        return true
    }
    return false
}

Kapcsolati ellenállóképesség

Azure SQL Database időnként újrakonfigurálja szervereket frissítésekhez, failoverekhez és terhelés egyensúlyozásához. Ezek az események megszakítják a meglévő kapcsolatokat, amelyek driver: bad connection hibákként jelennek meg. Konfiguráld a poolodat automatikusan a helyreállításra:

db.SetConnMaxLifetime(5 * time.Minute)  // Rotate connections so stale ones are replaced.
db.SetConnMaxIdleTime(2 * time.Minute)  // Recycle before Azure gateway drops idle connections (30 min).
db.SetMaxIdleConns(10)                  // Keep warm connections for quick recovery.

Megjegyzés:

Az Azure SQL átjáró lezárja azokat a kapcsolatokat, amelyek körülbelül 30 percig tétlen vannak. Állítsa a ConnMaxIdleTime értékét jóval ezen küszöbérték alá, hogy elkerülje a driver: bad connection hibákat az üresjárati időszak utáni első lekérdezés során. Nem tranzakciós hívások esetén database/sql automatikusan újrapróbálkozik egy új kapcsolaton. Tranzakciós hívások esetén a kódodnak el kell találnia a hibát, és újra kell próbálkoznia az egész tranzakcióval.

Újracsatlakozás a failover után

Tranzakción kívül a database/sql észrevétlenül újrapróbálhat egy hibás kapcsolaton induló hívást, amikor az illesztőprogram használhatatlannak jelöli a kapcsolatot. Ez a működés nem egy teljes átmenetihiba-újrapróbálási szabályzat a fojtás, a failover vagy más újrapróbálható SQL-hibák kezelésére. Foglald az adatbázishívásokat egy újrapróbálkozást kezelő függvénybe az ilyen helyzetek kezelésére:

var count int
err := RetryFunc(ctx, DefaultRetryConfig, func(ctx context.Context) error {
    return db.QueryRowContext(ctx, "SELECT COUNT(*) FROM HumanResources.Employee").Scan(&count)
})

Lásd: Hibakezelés és újrapróbálkozási minták a RetryFunc megvalósításhoz.

Azure SQL Managed Instance

Az Azure SQL Managed Instance ugyanazokat a driver-funkciókat támogatja, mint az on-premises SQL Server, néhány különbséggel:

Funkció	Azure SQL Database	Azure SQL Managed Instance
SQL Server-ügynök	Nem elérhető	Available
Adatbázisközi lekérdezések	Nem elérhető	Available
Csatolt kiszolgálók	Nem elérhető	Available
Névvel ellátott csövek	Nem elérhető	Nem elérhető (csak TCP)
Megosztott memória	Nem elérhető	Nem elérhető (csak TCP)
Windows-hitelesítés (SSPI)	Nem elérhető	Elérhető a kezelt VNet-en belül

Csatlakozz egy Managed Instance-hoz:

sqlserver://<user>:<password>@<instance>.database.windows.net?database=<database>&encrypt=true&TrustServerCertificate=false

SQL-adatbázis a Microsoft Fabricben

Important

Az SQL adatbázis a Fabric-ben Microsoft Entra ID hitelesítést igényel. Az SQL Server hitelesítés nem támogatott.

Éles munkaterhelések esetén az új kapcsolatoknál jelentkező, a hitelesítőadat-lánc vizsgálatából adódó többletterhelés elkerülése érdekében a ActiveDirectoryDefault helyett inkább a kifejezett fedauth módot használja.

A Fabricben működő SQL-adatbázis támogatja az go-mssqldb illesztőprogramot Microsoft Entra ID-hitelesítéssel:

db, err := sql.Open("azuresql",
    "sqlserver://<server>.database.fabric.microsoft.com?database=<database>&fedauth=ActiveDirectoryDefault&encrypt=true&TrustServerCertificate=false")
if err != nil {
    panic(err)
}

Tippek az Azure SQL teljesítményének javításához

Tip	Részletek
Használjon kapcsolat-kötegelést	Azure SQL minden nyílt kapcsolatot a tier limit közé számol. Tartsd MaxOpenConns korlátok között.
encrypt=strict engedélyezése	A legerősebb biztonsághoz használjuk TDS 8.0 titkosítást: encrypt=strict. Azure SQL Database támogatja a strict mode-ot.
Használja a ApplicationIntent=ReadOnly-t	Irányítsa az olvasásintenzív lekérdezéseket az olvasási replikákhoz: ApplicationIntent=ReadOnly. Elérhető Premium, Business Critical és Hyperscale szinteken.
Figyeld a DTU/vCore használatát	A magas CPU, IO vagy worker használat azt jelzi, hogy a szinted alulméretezett lehet. Az Azure Monitor használatával nyomon követheti az erőforrás-kihasználást.
Tartsd röviden a tranzakciókat	Az Azure SQL olyan tranzakciókat zár le, amelyek meghaladják az erőforrás küszöbértékeket (hiba 40549).
Régiónkénti végpontok használata	Helyezd az alkalmazást ugyanabba az Azure régióba, mint az adatbázis, hogy minimalizáld a késleltetést.

Azure SQL hibaelhárítási ellenőrzőlista

Hibajelenség	Valószínű ok	Solution
Cannot open server	Tűzfal szabály hiányzik	Add hozzá az IP-det vagy engedélyezd az Azure szolgáltatások hozzáférését.
Login failed	Rossz hitelesítő adatok vagy hiányzó adatbázis-felhasználó	Ellenőrizd, hogy a bejelentkezés létezik és adatbázishoz fér hozzá.
A kapcsolatok időnkénti levonásai	Szerver újrakonfigurálása vagy failover-e	Valósítsd meg újrapróbálkozási logikát és kapcsolat rotációját.
Resource limit reached	Túl sok egyidejű kapcsolat	Csökkentse a(z) MaxOpenConns értékét, és zárja le azonnal a kapcsolatokat.
The service is currently busy	Azure SQL throttling	Próbálkozzon újra exponenciális visszalépéssel. Fontold meg a felskálázást.
Korábban jól működő lekérdezések lelassulása	DTU/vCore kimerülése	Ellenőrizze az Azure Monitor metrikákat. Skálázd vagy optimalizáld a lekérdezéseket.

Kapcsolódó tartalom

• Quickstart: Use Golang to query Azure SQL Database
• Microsoft Entra ID-hitelesítés
• Hibakezelés és újrapróbálkozási minták
• Kapcsolatkészletezés
• Titkosítás és tanúsítványok
• Teljesítmény finomhangolása