Problem bei Erstellung einer Replikation in MSSQL 2022 auf Ubuntu 20.04
Aufgabe:
Ich versuche, eine Replikation auf Microsoft SQL Server 2022 zu konfigurieren, der auf einem Ubuntu 20.04-Server läuft. Die Replikation soll zwischen zwei SQL Server-Instanzen eingerichtet werden.
Tools:
sqlcmd
Microsoft SQL Server Management Studio (MSSMS) 20.2
SQL Server 2022 auf Ubuntu 20.04
Nach der Konfiguration des Distributors erhalte ich beim Versuch eine Meldung:
In dem nächsten Feld ist der Server bereits als Publisher aktiviert, mit dem Benutzer 'sa' und Password. Ich kann in diesem Fenster nichts weiteres einstellen und wenn ich es schließe, erhalte ich erneut die Meldung
Was ich noch gemacht habe:
Sicherstellen, dass SQL Server Agent auf dem Ubuntu-Server läuft.
Das mssql Servicekonto zu Administratorrechten auf dem Server hinzugefügt.
Berechtigungen für die Replikationsdatenbanken und das Verzeichnis (/mnt/data/ReplData) überprüft und angepasst.
Der SQL Server-Dienst wurde neu gestartet, um Änderungen zu übernehmen.
Trotz dieser Maßnahmen bleibt das Problem bestehen. Es scheint, dass MSSMS das Ubuntu-Server-Setup und das mssql Servicekonto nicht richtig erkennt.
Weiter habe ich auf dieser Seite
learn.microsoft.com/en-us/sql/linux/sql-server-linux-replication-tutorial-tsql?view=sql-server-ver16
die Befehle über T-SQL ausgeführt, bin aber auch nicht weitergekommen. Auf einigen Foren habe ich dieses gleiche Problem gefunden, aber keine Antwort. Daher habe ich den Verdacht, daß das MSSMS nicht richtig mit dem MSSQL auf Linux kommuniziert.
Diese Aufgabe erledige ich im Rahmen eines Lehrgangs für Datenbanken und verwende den MSSQL in der Einstellung als Developer. Die beiden SQL-Server laufen auf VM (gehostet auf TrueNAS).
Für eine Hilfestellung wäre ich sehr danbkbar, selbst wenn es um die Klärung geht, daß das MSSMS nicht geeignet ist. Falls dies der Fall ist, würde es mich interessieren, ob wenigstens die SQL-Abfragen verläßlich sind, denn diese sind für mich einfacher zu bewältigen, als das Copy&Paste über die sqlcmd-Konsole.
Ich versuche, eine Replikation auf Microsoft SQL Server 2022 zu konfigurieren, der auf einem Ubuntu 20.04-Server läuft. Die Replikation soll zwischen zwei SQL Server-Instanzen eingerichtet werden.
Tools:
sqlcmd
Microsoft SQL Server Management Studio (MSSMS) 20.2
SQL Server 2022 auf Ubuntu 20.04
Nach der Konfiguration des Distributors erhalte ich beim Versuch eine Meldung:
Der Server sql1.mysite.com muss als Publisher aktiviert werden, bevor Sie eine Publikation erstellen können. Aktivieren Sie diesen Server als Publisher im folgenden Dialogfeld.
In dem nächsten Feld ist der Server bereits als Publisher aktiviert, mit dem Benutzer 'sa' und Password. Ich kann in diesem Fenster nichts weiteres einstellen und wenn ich es schließe, erhalte ich erneut die Meldung
Der Server sql1.mysite.com muss als Publisher aktiviert werden, bevor Sie eine Publikation erstellen können. Aktivieren Sie diesen Server als Publisher im folgenden Dialogfeld.
Was ich noch gemacht habe:
Sicherstellen, dass SQL Server Agent auf dem Ubuntu-Server läuft.
Das mssql Servicekonto zu Administratorrechten auf dem Server hinzugefügt.
Berechtigungen für die Replikationsdatenbanken und das Verzeichnis (/mnt/data/ReplData) überprüft und angepasst.
Der SQL Server-Dienst wurde neu gestartet, um Änderungen zu übernehmen.
Trotz dieser Maßnahmen bleibt das Problem bestehen. Es scheint, dass MSSMS das Ubuntu-Server-Setup und das mssql Servicekonto nicht richtig erkennt.
Weiter habe ich auf dieser Seite
learn.microsoft.com/en-us/sql/linux/sql-server-linux-replication-tutorial-tsql?view=sql-server-ver16
die Befehle über T-SQL ausgeführt, bin aber auch nicht weitergekommen. Auf einigen Foren habe ich dieses gleiche Problem gefunden, aber keine Antwort. Daher habe ich den Verdacht, daß das MSSMS nicht richtig mit dem MSSQL auf Linux kommuniziert.
Diese Aufgabe erledige ich im Rahmen eines Lehrgangs für Datenbanken und verwende den MSSQL in der Einstellung als Developer. Die beiden SQL-Server laufen auf VM (gehostet auf TrueNAS).
Für eine Hilfestellung wäre ich sehr danbkbar, selbst wenn es um die Klärung geht, daß das MSSMS nicht geeignet ist. Falls dies der Fall ist, würde es mich interessieren, ob wenigstens die SQL-Abfragen verläßlich sind, denn diese sind für mich einfacher zu bewältigen, als das Copy&Paste über die sqlcmd-Konsole.
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 671713
Url: https://administrator.de/forum/problem-bei-erstellung-einer-replikation-in-mssql-2022-auf-ubuntu-20-04-671713.html
Ausgedruckt am: 15.04.2025 um 13:04 Uhr
10 Kommentare
Neuester Kommentar
Moinsen
MS SQL Replikation unter Linux ist etwas tricky, da Microsoft Dienste (MSDTC) oft RPC als Protokoll nutzen.
Ich hab z.B. eine Merger Repliaktion (lt. MS offiziell nicht möglich) mit drei MS SQL Server 2022 als Testsystem ebenfalls mit der DEV Edition am Laufen. Allerdings unter Ubuntu 22.04.5 (Proxmox VM - kein LXC!)
https://learn.microsoft.com/de-de/sql/linux/sql-server-linux-configure-m ...
hier mal meine mssql.conf unter /var/opt/mssql/
MS SQL Replikation unter Linux ist etwas tricky, da Microsoft Dienste (MSDTC) oft RPC als Protokoll nutzen.
Ich hab z.B. eine Merger Repliaktion (lt. MS offiziell nicht möglich) mit drei MS SQL Server 2022 als Testsystem ebenfalls mit der DEV Edition am Laufen. Allerdings unter Ubuntu 22.04.5 (Proxmox VM - kein LXC!)
https://learn.microsoft.com/de-de/sql/linux/sql-server-linux-configure-m ...
hier mal meine mssql.conf unter /var/opt/mssql/
[sqlagent]
enabled = true
[licensing]
azurebilling = false
[EULA]
accepteula = Y
[language]
lcid = 1031
[filelocation]
defaultdatadir = /var/mssql/data
[network]
tcpport = 1433
rpcport = 13500
[distributedtransaction]
servertcpport = 51999
allowonlysecurerpccalls = 0
fallbacktounsecurerpcifnecessary = 0
turnoffrpcsecurity = 1
[uncmapping]
//mssql-biz/repldata = /var/opt/mssql/ReplData
Also ich habe schon des Öfteren gelesen das MSSQL auf Linux eher ein nettes Gimmick ist, als eine ernstzunehmende Alternative. Vermutlich setzt nicht mal MS das ein, es wird also immer Einschränkungen geben und wenig Priorität genießen.
Das Warum bezog sich daher auf die Frage, warum die DB nicht einfach auf Windows liegt. Wenn du sagst, weil ich kein Windows Server habe, dann okay, das kann ich nachvollziehen. Ich weiß ja auch nicht wie viel davon abhängt aber ich würde davon absehen es einfach zu machen weil man es kann.
Von JTL habe ich übrigens noch eine viel schlechtere Meinung
Das würde ich gar nicht einsetzen wollen, das ist so gruselig. Ich habe mal versucht, aus JTL Buchungen (gruppiert nach steuerlichen Sachverhalten) und Rohdaten + zugehörige Daten von Vorsystemen zu verstehen, wie die Summen zustande kommen. Das war nicht möglich, das sollte es in einer Buchführung aber irgendwie sein. Rund um das Thema habe ich dann viel schlechten Support und schlechtes Produktdesign erlebt. Außerdem kam kurze Zeit später das mit den hart kodierten Passwörtern in den Medien...
Das Warum bezog sich daher auf die Frage, warum die DB nicht einfach auf Windows liegt. Wenn du sagst, weil ich kein Windows Server habe, dann okay, das kann ich nachvollziehen. Ich weiß ja auch nicht wie viel davon abhängt aber ich würde davon absehen es einfach zu machen weil man es kann.
Von JTL habe ich übrigens noch eine viel schlechtere Meinung
solang die SQL Server nicht über eine öffentliche Verbindung kommunizieren würde ich immer die Optionen Trust Server Certificate und optionale Encryption nutzen - auch im SSMS
Prinzipiell ist aber keine gute Idee, Datenbanken in ein öffentliches Netz zu stellen.
Du kannst Dir am besten im SSMS beide Server verbinden und die Replikation auch per GUI zusammenklicken
Prinzipiell ist aber keine gute Idee, Datenbanken in ein öffentliches Netz zu stellen.
Du kannst Dir am besten im SSMS beide Server verbinden und die Replikation auch per GUI zusammenklicken