Verwenden von go-mssqldb mit Azure SQL-Datenbank

Der Treiber go-mssqldb unterstützt die Verbindung mit Azure SQL-Datenbank, Azure SQL Managed Instance und SQL Database in Microsoft Fabric. Dieser Artikel behandelt Azure-spezifische Konfigurationen, Authentifizierung, Verbindungsgrenzen und Fehlerbehebung, die sich vom lokalen SQL Server unterscheiden.

Herstellen einer Verbindung mit Azure SQL-Datenbank

Azure SQL-Datenbank benötigt standardmäßig verschlüsselte Verbindungen. Spezifiziere encrypt=true und TrustServerCertificate=false explizit so, dass die Verbindung TLS verwendet und das Serverzertifikat validiert:

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

Verwenden Sie passwortlose Authentifizierung (empfohlen)

Die Microsoft Entra ID-Authentifizierung entfernt Passwörter aus Ihren Verbindungszeichenketten. ActiveDirectoryDefault Wählt automatisch die beste verfügbare Zugangsberechtigung für die Umgebung aus, was die Entwicklung erleichtert:

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()
}

Wie ActiveDirectoryDefault Zugangsdaten auflöst

ActiveDirectoryDefault Versucht die folgenden Zugangsquellen der Reihe nach und verwendet die erste, die erfolgreich ist:

Diese Anmeldeinformationskette macht die Verwendung von ActiveDirectoryDefault während der Entwicklung einfach, aber die sequenzielle Überprüfung führt bei jeder neuen Verbindung zu zusätzlicher Latenz. Für die Produktion geben Sie die genaue Authentifizierungsmethode (wie ActiveDirectoryManagedIdentity) an, damit der Treiber unnötige Überprüfungen überspringt.

Verwaltete Identität für die Produktion (empfohlen)

Anwendungen, die in Azure gehostet werden (App Service, Container Apps, Azure Functions oder Azure VMs), sollten eine verwaltete Identität mit einem expliziten fedauth Wert verwenden. Dieser Ansatz vermeidet den Credential-Chain-Overhead und eliminiert jegliche Abhängigkeit von Umgebungsvariablen oder CLI-Zuständen.

Vom System zugewiesene verwaltete Identität:

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

Benutzerzugewiesene verwaltete Identität (geben Sie die Client-ID an):

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

Gewähren Sie den Identitätszugriff in der Datenbank

Nachdem Sie die verwaltete Identität auf der Azure-Ressource konfiguriert haben, erstellen Sie einen integrierten Datenbankbenutzer:

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];

Für systemzugewiesene Identitäten verwenden Sie den Azure-Ressourcennamen. Für benutzerdefinierte Identitäten verwenden Sie den Identitätsnamen.

Serviceprinzip für Automatisierung

Für CI/CD-Pipelines oder Service-to-Service-Authentifizierung:

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

Für alle Zugangsdaten siehe Microsoft Entra ID Authentifizierung.

Konfigurieren der Azure-Firewall

Azure SQL-Datenbank verwendet eine Server-Level-Firewall. Sie müssen die öffentliche IP-Adresse Ihres Kunden zulassen oder einen privaten Endpunkt verwenden.

Fehler: Server kann nicht geöffnet werden

Diese Fehlermeldung zeigt an, dass die Azure-Firewall Ihre Client-IP-Adresse blockiert:

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

Lösungen :

1. Füge eine Firewall-Regel im Azure-Portal hinzu: SQL Server>Networking>Füge eine Firewall-Regel hinzu.
2. Aktivieren Sie den Zugriff auf Azure-Dienste und -Ressourcen auf diesen Server, wenn Ihre Anwendung in Azure läuft.
3. Für die private Verbindung konfigurieren Sie einen privaten Endpunkt.

Fehler: Verbindung ist ausgelaufen

Wenn die Verbindung ohne klaren Fehler abläuft, blockiert die Firewall die Verbindung wahrscheinlich stillschweigend. Überprüfe zuerst die Firewall-Regeln.

Verbindungsgrenzen nach Dienststufe

Azure SQL-Datenbank erzwingt Verbindungslimits pro Datenbank basierend auf der Service-Schicht. Das Überschreiten des Limits führt zu Authentifizierungsfehlern bei neuen Verbindungen. Die vollständigen Grenzwerttabellen finden Sie unter DTU-Ressourcengrenzwerte für einzelne Datenbanken und vCore-Ressourcengrenzwerte für einzelne Datenbanken.

Setze MaxOpenConns so ein, dass sie zu deiner Stufe passen

Setze MaxOpenConns immer einen Wert unterhalb des Verbindungslimits für dein Azure SQL-Tier:

// 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)

Azure SQL-Drosselung behandeln

Die Azure SQL-Datenbank kann Verbindungen und Abfragen drosseln, wenn die Datenbank Ressourcengrenzen (CPU, IO, Speicher oder Sitzungsanzahl) erreicht. Drosselung äußert sich in bestimmten Fehlernummern.

Häufige Drosselungsfehler

Erneute Drosselungsanfragen

Die meisten Azure SQL-Throttling- und Verfügbarkeitsfehler in der vorangegangenen Tabelle sind vorübergehend und sollten mit exponentiellem Backoff erneut versucht werden. Der Fehler 40544 ist nicht vorübergehend. Das bedeutet, dass die Datenbank ihre Größenquote erreicht hat, sodass die Operation erst erfolgreich ist, wenn man die Datenbank hochskaliert oder Daten löscht.

Für eine vollständige Retry-Implementierung siehe Fehlerbehandlung und Retry-Patterns.

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
}

Verbindungsresilienz

Azure SQL-Datenbank konfiguriert gelegentlich Server für Updates, Failovers und Lastverteilung neu. Diese Ereignisse lassen bestehende Verbindungen fallen, die als driver: bad connection Fehler sichtbar werden. Konfigurieren Sie Ihren Pool so, dass er sich automatisch wiederherstellt:

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.

Wiederverbindung nach Failover

Außerhalb von Transaktionen kann database/sql einen Aufruf, der über eine fehlerhafte Verbindung gestartet wird, transparent wiederholen, wenn der Treiber die Verbindung als unbrauchbar markiert. Dieses Verhalten ist keine vollwertige Wiederholungsrichtlinie für vorübergehende Fehler bei Drosselung, Failover oder anderen SQL-Fehlern, bei denen ein erneuter Versuch möglich ist. Packen Sie Ihre Datenbankaufrufe in eine Retry-Funktion ein, um diese Szenarien zu handhaben:

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

Siehe Fehlerbehandlung und Wiederholungsmuster für die RetryFunc Implementierung.

Verwaltete Azure SQL-Instanz

Azure SQL Managed Instance unterstützt dieselben Treiberfunktionen wie der lokale SQL Server, mit einigen Unterschieden:

Verbinden Sie sich mit einer verwaltete Instanz:

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

SQL-Datenbank in Microsoft Fabric

Die SQL-Datenbank in Fabric unterstützt den go-mssqldb Treiber mit Microsoft Entra ID-Authentifizierung:

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

Azure SQL-Leistungstipps

Checkliste zur Problembehandlung für Azure SQL

Verwandte Inhalte

• Quickstart: Verwenden Sie Golang, um Azure SQL-Datenbank abzufragen
• Microsoft Entra ID-Authentifizierung
• Fehlerbehandlung und Wiederholungsmuster
• Verbindungspooling
• Verschlüsselung und Zertifikate
• Leistungsoptimierung