Neu Linux / MSSQL und WaWi

[Voltmaster]

Hallo zusammen,

leider hatten wir heute Nacht den SuperGau und unser geliebter lokaler WindowsServer hat sich verabschiedet... Über Nacht mussten wir kurz einen Client zum "Server" umfunktionieren, damit es weiter geht.

Nun beginnt die HardwareSuche und wir überlegen gerade, ob evtl sogar ein weiterer Linux Server ins Haus kommt....
Gibt es aktuell bekannte Probleme mit SQL Server 2019 Standard und Linux im Zusammenhang mit der WaWi?
Oder würdet Ihr davon komplett abraten?

Warum Linux? Wir haben im Bereich Server einfacher mehr Erfahrung im Bezug auf Linux und könnten das besser und einfacher selbst supporten....

 

[recent.digital]

Es gibt einige Mitforisten die Linux und SQL gut betreiben - Vorkenntnisse vorrausgesetzt.

Hier gibt es noch einen ausführlichen Foren-Thread, wenn auch etwas älter: https://forum.jtl-software.de/threads/mssql-server-linux-docker.97137/

 

[sjk]

Was man auch noch bedenken sollte ist, dass JTL den SQL auf Linux (noch?) nicht offiziell supportet. Ich würde daher auf jeden Fall zuerst mal ein Testsystem aufsetzen, mal backup/restore etc. und paar andere Szenarien durchspielen. Dann werdet ihr selbst einschätzen können, ob Ihr euch damit wohl fühlen würdet.
Im anderen Thread siehst du ja, grundsätzlich rennt es auf Linux aber es gibt, mangels offiziellem Support, ein paar Stolpersteine.

 

[mh1]

Da du ja schreibst, dass ihr hausintern besser ein linuxbasierendes Betriebssystem supporten könnt, würd ich ja zu einem solchen System raten.

In der Administration der Datenbank merkst du dann eh nicht mehr ob mssql auf Windows oder Ubuntu oder RedHat oder sonstwas läuft

Die Installation bzw. die Konfiguration des mssql erfolgt auf einem Windows System eben Windows-typisch, indem man sich mit der Maus durch bunte Fenster klickt und auf einem linuxbasierten System editiert man eine Textdatei. Mir persönlich gefällt der Weg über die conf Datei viel besser, aber letztlich muss da jeder selbst schauen, mit was man besser zurecht kommt - denn genau um das gehts: man muss damit gut zurechtkommen (wie mache ich ein Backup? wie einen Restore?...)

Aber auf jedenfall stimme ich meinem Vorredner zu, dass ein Testsystem hilfreich ist.

 

[Dom@H1]

Dann gebe ich hier auch noch meine Meinung dazu:

Ich mag Linux sehr und arbeite mit Debian und Ubuntu für verschiedene Aufgaben.
Persönlich empfehle ich gerne Proxmox als Hypervisor, mit dem man ja schon viele Linux Vorteile nutzen kann.
Warum ich sehr häufig die Windows VM empfehle, liegt am Support durch JTL. Solltet Ihr keinen Support benötigen, dann ist eine eine Linux VM/LXC Container oder Docker Container in Proxmox eine sehr gute Lösung.
Damit habt ihr dann Testsysteme schnell verfügbar und Backups/Snapshots sind auch einfach zu konfigurieren.

 

[Powalowski]

Dann gebe ich hier auch noch meine Meinung dazu:

Ich mag Linux sehr und arbeite mit Debian und Ubuntu für verschiedene Aufgaben.
Persönlich empfehle ich gerne Proxmox als Hypervisor, mit dem man ja schon viele Linux Vorteile nutzen kann.
Warum ich sehr häufig die Windows VM empfehle, liegt am Support durch JTL. Solltet Ihr keinen Support benötigen, dann ist eine eine Linux VM/LXC Container oder Docker Container in Proxmox eine sehr gute Lösung.
Damit habt ihr dann Testsysteme schnell verfügbar und Backups/Snapshots sind auch einfach zu konfigurieren.

So muss das. Wir warten eigentlich alle nur noch darauf, dass die WAWI endlich vernünftig auf API umgebaut, im Docker hostbar und ganz ohne Windows nutzbar wird 😋😋😋

 

[Voltmaster]

Danke für Eure Mithilfe / Infos hier!
Unser DB-Backup haben wir mit einigen Umwegen gleich von den Collation-Problemen befreit und eingespielt.

Inzwischen rennt unser System seit ca. 1 Woche auf dem alten Server aber unter Ubuntu....
Noch keine Probleme.
Backup läuft auch auf mehrere Rechner und Platten...

Einziges "Problem" ist aktuell noch das Starten der WaWi 1.9.4.5. Das ist auf jedem Client extrem lahm.
Evtl hat mir da ja jemand noch einen Trick oder eine Info, wo das Problem liegen könnte...

Nächste Woche werden wir da mal einen schnelleren "Testserver" mit ordentlich NVMe und RAM probieren.... sollte das das Problem lösen, muss halt einfach was neues her oder man muss etwas warten

DANKE!

 

[Powalowski]

Wenn es um die Konfiguration geht, müssten die Standardoptimierungen gelten.
Ich nehm an, ihr habt den im Docker: Wie macht ihr denn die Backup-Routine? Zieht ihr die .baks aus dem Docker raus?

 

[recent.digital]

Danke für das Feedback! Wo läuft der Worker in dieser Konstellation?

 

[Voltmaster]

Der MSSQL 2022 Standard läuft direkt auf dem Server....

Backup:
läuft via ShellScript.
einmal um 3 Uhr volles Backup,
Danach jede Stunde ein DiffBackup
Das Script kopiert das Backup erst auf die lokale Disk, dann komprimiert nochmal lokal auf ein Raid und dann auf ein gemountetes SMB-Share.
Zusätzlich ist eine Sicherung per Copy auf USB Stick geplant.
Alte Backups > 10 Tage werden gelöscht, Diff Backups > 2 Tage

Der Worker läuft auch auf dem Server in einer WindowsLTSC-VirtualBox

 

[Fabrice]

Wir nutzen Die Datenbank in Docker. Bis auf das sich der Support manchmal ziert weil es kein Windows ist, läuft es mega stabil und perfomant. Man kann die Datenbank auch Bare Metal oder in einer VM installieren aber über Docker fand ich es einfacher und deshalb nutzen wir es so.
Updates und Upgrades sind eine Sache von Sekunden. Backups macht der SQL Server selbst. Zusätzlich ist die VM in der der Container läuft in unserem Backup. Handling von Backups ist finde ich über die CLI deutlich angenehmer als über das SMSS.

SMSS lässt sich dennoch sehr gut nutzen. Es gibt ein paar Features, welche es unter Linux nicht gibt. Zumindest nicht ohne weiteres: Filestream mal als Beispiel.

https://learn.microsoft.com/en-us/s...known-issues?view=sql-server-ver16&tabs=rhel9

Worker läuft auf einer separaten Maschine unter Windows.

 

[Powalowski]

Wir nutzen Die Datenbank in Docker. Bis auf das sich der Support manchmal ziert weil es kein Windows ist, läuft es mega stabil und perfomant. Man kann die Datenbank auch Bare Metal oder in einer VM installieren aber über Docker fand ich es einfacher und deshalb nutzen wir es so.
Updates und Upgrades sind eine Sache von Sekunden. Backups macht der SQL Server selbst. Zusätzlich ist die VM in der der Container läuft in unserem Backup. Handling von Backups ist finde ich über die CLI deutlich angenehmer als über das SMSS.

SMSS lässt sich dennoch sehr gut nutzen. Es gibt ein paar Features, welche es unter Linux nicht gibt. Zumindest nicht ohne weiteres: Filestream mal als Beispiel.

https://learn.microsoft.com/en-us/s...known-issues?view=sql-server-ver16&tabs=rhel9

Worker läuft auf einer separaten Maschine unter Windows.

Same same. Wie genau macht ihr die Backups?

 

[mh1]

Same same. Wie genau macht ihr die Backups?

Du hast zwar nicht MICH gefragt, aber ich bin trotzdem mal so frech und antworte. Deshalb schreibe ich, wie ich es mache, nämlich ziemlich einfach (KISS-Prinzip):

• Ich habe eine kleine Stored Procedure auf dem SQL-Server angeleget, die einen sinnvollen Dateinamen für die Backupdatei bastelt und entscheidet, welche Art von Backup gemacht werden soll (z.b. "with differential")
• Auf dem Host auf dem der sqlserver läuft ist ein simpler Cronjob eingerichtet, der regelmäßig diese SP ausführt (so in der Art: sqlcmd -Q "EXEC sp_Backup")

Jetzt kann man die erstellte Backupdatei noch nach belieben irgendwohin kopieren (z.b. einfach an den Cronjob noch ein && scp soundso anhängen, oder auf eine externe Platte schieben), oder oder ...

 

[Fabrice]

Du hast zwar nicht MICH gefragt, aber ich bin trotzdem mal so frech und antworte. Deshalb schreibe ich, wie ich es mache, nämlich ziemlich einfach (KISS-Prinzip):

• Ich habe eine kleine Stored Procedure auf dem SQL-Server angeleget, die einen sinnvollen Dateinamen für die Backupdatei bastelt und entscheidet, welche Art von Backup gemacht werden soll (z.b. "with differential")
• Auf dem Host auf dem der sqlserver läuft ist ein simpler Cronjob eingerichtet, der regelmäßig diese SP ausführt (so in der Art: sqlcmd -Q "EXEC sp_Backup")

Jetzt kann man die erstellte Backupdatei noch nach belieben irgendwohin kopieren (z.b. einfach an den Cronjob noch ein && scp soundso anhängen, oder auf eine externe Platte schieben), oder oder ...

Genau so