Microsoft leitet letzte Phase für SQL Data Sync ein

Microsoft hat die nächste Stufe bei der Einstellung von SQL Data Sync gezündet: Seit dem 9. September lassen sich in Azure-Abonnements, die den Dienst bislang nicht genutzt haben, keine neuen SQL-Data-Sync-Bereitstellungen mehr anlegen. Bestehende Nutzer können Sync-Gruppen und Mitgliedsdatenbanken dagegen noch bis zum vollständigen Aus des Dienstes am 30. September 2027 erstellen, ändern und betreiben.

Die Einstellung hatte Microsoft bereits 2024 mit dreijähriger Übergangsfrist angekündigt. SQL Data Sync gleicht ausgewählte Daten zwischen mehreren Datenbanken ab, sowohl zwischen Azure SQL Database als auch mit SQL-Server-Instanzen im eigenen Rechenzentrum. Die Daten können dabei je nach Konfiguration in beide Richtungen fließen. Microsoft beschreibt die Einstellung und die vorgesehenen Migrationspfade in seiner Dokumentation.

Keine Einschränkung für bestehende Abonnements

Die neue Einschränkung trifft ausdrücklich ausschließlich Azure-Abonnements, die SQL Data Sync zuvor nie eingesetzt haben. Für Abonnements, die SQL Data Sync bereits nutzen, ändert sich zunächst nichts: Administratoren dürfen weiterhin Sync-Gruppen anlegen und verwalten sowie Datenbanken als Mitglieder hinzufügen. Microsoft will damit verhindern, dass kurz vor dem Endtermin noch neue Abhängigkeiten von dem auslaufenden Dienst entstehen. Die Details zur nun begonnenen letzten Ausmusterungsphase nennt Microsoft im Azure-SQL-Blog.

SQL Data Sync organisiert die Replikation in Sync-Gruppen nach einem Hub-and-Spoke-Prinzip. Als Hub dient stets eine Azure SQL Database; weitere Azure-SQL-Datenbanken oder SQL-Server-Datenbanken können als Mitglieder teilnehmen. Bei lokalen SQL-Server-Datenbanken ist zusätzlich ein lokaler Sync-Agent nötig. Der Dienst kann Daten in beide Richtungen oder nur vom Hub zu einem Mitglied beziehungsweise umgekehrt übertragen.

Inventur vor der Migration

Microsoft rät betroffenen Organisationen, zunächst alle vorhandenen Bereitstellungen zu erfassen – auch inaktive Sync-Gruppen. Dazu gehören Hub- und Mitgliedsdatenbanken, gegebenenfalls installierte Sync-Agenten sowie die Anwendungen, die auf replizierte Daten angewiesen sind. In kleineren Umgebungen lassen sich die Sync-Gruppen über den Bereich „Sync to other databases“ einer Azure SQL Database im Azure-Portal prüfen. Für größere Azure-Landschaften verweist Microsoft auf die PowerShell und die Azure-SQL-Management-REST-API.

Vor der Umstellung sollten Administratoren außerdem Datenfluss, Synchronisierungsrichtung, Intervall, Datenvolumen sowie Anforderungen an Latenz und Verfügbarkeit festhalten. Das ist wichtig, weil SQL Data Sync kein einheitliches Nachfolgeprodukt erhält. Je nach bisherigem Einsatz kann die Migration eine bloße Umkonfiguration sein oder einen Umbau der Replikationsarchitektur erfordern.

Ersatz hängt vom Einsatzfall ab

Für geplante oder inkrementelle Übertragungen nennt Microsoft Azure Data Factory als Alternative. Das eignet sich etwa, wenn Daten in festen Intervallen für ein Data Warehouse oder einen Reporting-Bestand kopiert werden sollen. Für die einseitige Verteilung von SQL Server zu Azure SQL Database verweist der Konzern auf die transaktionale Replikation.

Geht es vor allem um lesende Replikate oder regionale Verfügbarkeit, kommen etwa aktive Georeplikation und Read Replicas infrage. Für Reporting-Replikate vollständiger Datenbanken nennt Microsoft Always On Availability Groups bei SQL Server auf Azure-VMs sowie Managed Instance Link bei Azure SQL Managed Instance. Daneben führt die Migrationsdokumentation Azure Functions mit Azure-SQL-Triggern für anwendungsspezifische Synchronisation sowie Mirroring in Microsoft Fabric für Analyseumgebungen auf. Welche Variante passt, hängt unter anderem von Quell- und Zielplattform, Datenrichtung, Topologie, zulässiger Verzögerung und Durchsatz ab. Die Migrationsdokumentation enthält dazu eine Übersichtstabelle, die alle Pfade nach Quell- und Zielplattform aufschlüsselt.

Nach erfolgreicher Validierung der Ersatzlösung in einer Nicht-Produktivumgebung empfiehlt Microsoft, die automatische Synchronisierung der bisherigen Gruppe vorübergehend abzuschalten. Erst wenn Anwendungen nicht mehr auf SQL Data Sync angewiesen sind, sollten Unternehmen die alten Ressourcen entfernen. Spätestens zum 30. September 2027 muss der Umstieg abgeschlossen sein.