Hallo Leute! Ich hab bei mir eine kleine Datenbank 200mb auf einem Server (SQL Express) in meinem kleinen Netz laufen. Läuft auch alles soweit sogut. Nun bin ich aber manchmal nicht da und nur jemand mit wenig bis gar keiner Computer Erfahrung vor Ort. Gebe es ein Möglichkeit die Datenbank irgendwie auf einem zweiten physischen Server zu spiegeln und wenn der erste Ausfällt übernimmt der zweite? Oder wie kriege ich das ganze Failsave? Danke Gruß
Kann die APP immer gleich in zwei Datenbanken schreiben?
Hi, ja ein NAS ist vorhanden. Mir geht es nicht darum das da was verloren geht sondern das ohne mich das niemand wiederherstellen kann. Leider kann die APP das nicht. Gruß
Tom schrieb: > irgendwie auf einem zweiten physischen Server zu spiegeln Wenn Du nur spiegelst, kann der gleiche Befehl auch den Spiegel zerstören. Du solltest besser mehrere Backups mit verschiedenen Ständen haben.
Für SQL Server gibt es "Fail Over Cluster". Allerdings nicht für die Express Version. Das geht erst ab der Standard Version vom SQL Server. Fail Over kann genau deine Anforderungen erfüllen - 2 Server mit dem selben Datenbestand und der 2. übernimmt, wenn der erste Probleme hat. https://docs.microsoft.com/en-us/sql/sql-server/failover-clusters/windows/always-on-failover-cluster-instances-sql-server?view=sql-server-2017
oszi40 schrieb: > Tom schrieb: >> irgendwie auf einem zweiten physischen Server zu spiegeln > > Wenn Du nur spiegelst, kann der gleiche Befehl auch den Spiegel > zerstören. Du solltest besser mehrere Backups mit verschiedenen Ständen > haben. Hi wie gesagt mir fällt da nix ein! Wie kriege ich es hin einen Server mit Backup so laufen zu lassen das wenn er mal ausfällt trotzdem jemand ohne viel Computer Ahnung ihn wieder zum laufen kriegt.
Der Suchbegriff dazu ist auto failover. Bei SQL Express findest du aber nur den Ratschlag - SQL Server High-Availability Solutions kaufen. Selbst schreiben ist gar nicht so einfach. Sobald du in Urlaub bist, passiert irgend etwas, an das du nicht gedacht hast. Die Datenbankhersteller haben Jahrzehnte gebraucht, bis das bei allen Arten von Fehlern zuverlässig läuft. Ein Vorschlag wäre: Anschauen wie die Mysql das macht und überlegen, ob du das für die SQL Express nachbauen willst.
Danke! Gibts da was von MySql also sprich kostenlos dann baue ich meine Datenbank einfach auf MySql um.
Ja das mit SQL Server kannte ich nur halt muss man da gut Geld für blechen. Reicht da überhaupt nur 1 Lizenz? Die kostet ja auch schon 1000€
Tom schrieb: > Gibts da was von MySql also sprich kostenlos Ja, gibt es. Bei MySQL kann einen man einen Slave-Server als Replikat des Masters laufen lassen. Der fährt die Operationen des Masters nach. https://www.thomas-krenn.com/de/wiki/MySQL_Replikation
:
Bearbeitet durch User
Tom schrieb: > oszi40 schrieb: >> Tom schrieb: >>> irgendwie auf einem zweiten physischen Server zu spiegeln >> >> Wenn Du nur spiegelst, kann der gleiche Befehl auch den Spiegel >> zerstören. Du solltest besser mehrere Backups mit verschiedenen Ständen >> haben. > > Hi > wie gesagt mir fällt da nix ein! Wie kriege ich es hin einen Server mit > Backup so laufen zu lassen das wenn er mal ausfällt trotzdem jemand ohne > viel Computer Ahnung ihn wieder zum laufen kriegt. garnicht. je nach dem was ausfällt, von netz über serverhardware, betriebssystem, datenbank software, oder von nutzern erzeugte datenzerstörung braucht man jemanden der das analysieren und entsprechend reagieren kann. dafür gibts admins. bei oracle heisst eine failover database übrigens shadow database (prinzipiell ein einpielen der archive logs in eine zweite datenbank), oder RAC. da mysql von oracle übernommen wurde haben die dort vielleicht auch inzwischen andere begrifflichkeiten eingeführt. wenn es mysql ohne oracle und ohne lizenskosten sein soll, dann ist deren fork mariadb wohl die erste wahl.
Beitrag #5682995 wurde von einem Moderator gelöscht.
Beitrag #5683021 wurde von einem Moderator gelöscht.
Tom schrieb: > Vielen Dank für den Input hat mir schonmal sehr weitergeholfen! Nee, glaub' ich nicht. Einen sauberen HA-Cluster aufzusetzen, ist kein Kinderspiel und nicht mit einem Doppelklick auf Setup.EXE getan. Das ganz unabhängig davon, ob man nun die mit Abstand leistungsfähigste OpenSource-Datenbank PostgreSQL benutzen will, MySQL oder seine Ableger MariaDB oder MaxSQL, Oracle, DB2, MSSQL oder whatever. Von mir aus DRBD zusammen mit <whatever>. Was sind eigentlich ein Quorum oder ein Split-Brain? Nur so in den Raum gefragt. Die Replikation ist der einfachste Teil, spannend wird es mit Distributed Locking, Switch- und Failover, ... was davon ist in einem einfachen Master-Slave-Setup relevent, was vernachlässigbar? Was könnte dieses Ding mit dem Write-Ahead-Log sein? Und dann: 200 MB? Wäre da nicht was anderes als ein RDBMS angemessen? Welche Sicherheiten garantieren eigentlich RDBMS? Und wozu? ;-)
Sachte, lass ihn am Leben. ;-) Vollautomatischer Failover scheint nicht erforderlich zu sein, manueller Failover reicht offenbar: Tom schrieb: > wenn er mal ausfällt trotzdem jemand ohne > viel Computer Ahnung ihn wieder zum laufen kriegt. Bei MySQL Replikation ist ein manueller Failover mit der Abschaltung des Masters und der Aktivierung einer sekundären IP-Adresse auf dem Slave erledigt. Das kriegt man per Script jedem beigebogen, der eine Tastatur bedienen kann. Notfalls bringt man der Hauskatze bei, ein Netzwerkkabel umzustecken. Den Fallback kann er später selber machen, wenn er wieder da ist. Nun kann er sich mal meinen Link oben anschauen und sich schläuen, ob das was für ihn sein könnte. Wenn ja, ist das kein Hexenwerk. Wenn er dann noch drauf achtet, die transaktionsfähige Engine zu verwenden, dann ist doch eine nicht sehr anspruchsvolle Sache.
:
Bearbeitet durch User
A. K. schrieb: > Sachte, lass ihn am Leben. ;-) > > Vollautomatischer Failover scheint nicht erforderlich zu sein, manueller > Failover reicht offenbar: > > Tom schrieb: >> wenn er mal ausfällt trotzdem jemand ohne >> viel Computer Ahnung ihn wieder zum laufen kriegt. > > Bei MySQL Replikation ist ein manueller Failover mit der Abschaltung des > Masters und der Aktivierung einer sekundären IP-Adresse auf dem Slave > erledigt. Das kriegt man per Script jedem beigebogen, der eine Tastatur > bedienen kann. Notfalls bringt man der Hauskatze bei, ein Netzwerkkabel > umzustecken. > > Den Fallback kann er später selber machen, wenn er wieder da ist. > > Nun kann er sich mal meinen Link oben anschauen und sich schläuen, ob > das was für ihn sein könnte. Wenn ja, ist das kein Hexenwerk. Wenn er > dann noch drauf achtet, die transaktionsfähige Engine zu verwenden, dann > ist doch eine nicht sehr anspruchsvolle Sache. Ja genau so habe ich mir das ganze vorgestellt, manueller Failover ist völlig ausreichend!
A. K. schrieb: > Notfalls bringt man der Hauskatze bei, ein Netzwerkkabel > umzustecken. Irgendwelche Tips und Vorschläge dazu? :)
Reinhard S. schrieb: > Irgendwelche Tips und Vorschläge dazu? :) http://de.web.img3.acsta.net/r_1920_1080/medias/nmedia/18/35/23/93/18376392.jpg https://www.dictionary.com/e/wp-content/uploads/2018/04/neko.jpg https://www.tagesspiegel.de/images/kater-garfield/22705176/2-format6001.jpg?inIsFirst=true Je nachdem was zur Verfügung steht.
:
Bearbeitet durch User
Der MS SQL Server in der Express Version kann hier nicht viel. Er ist auch nicht unbedingt für solche Szenarien vorgesehen. Die Spiegelung braucht mindestens eine Standard Version. Das muss aber auch die Anwendung mitmachen. Mit einiges an scripten kann man eine SQL Express Version zum "Log Shipping" überzeugen. Damit kann man aber kein automatisches Failover umsetzen. Wenn die Datenbank mit ihren Daten bereits auf einem anderen Rechner "halb" läuft, kann man einiges an Zeit sparen. Das ganze ist nicht ganz ohne...
By the way: MySQL wurde durch MariaDB abgelöst - jedenfalls in der Welt jenseits von Oracle.
A. K. schrieb: > Tom schrieb: >> Gibts da was von MySql also sprich kostenlos > > Ja, gibt es. Bei MySQL kann einen man einen Slave-Server als Replikat > des Masters laufen lassen. Der fährt die Operationen des Masters nach. Besser wäre Galera Cluster (von MariaDB oder Percona Server). Da ist die Replikation synchron, man kann auf beide (bzw. alle) Nodes im Cluster schreiben und ein Proxy ist auch schon dabei. Backups braucht man aber natürlich trotzdem noch. Der Cluster schützt nur vor einem Hardware-Ausfall, nicht vor einer amoklaufenden Anwendung, einem Hack oder dem DBA, der im Tran wichtige Daten löscht. https://github.com/wenerme/wener/blob/master/articles/High%20Availability%20Solutions%20for%20the%20MariaDB%20and%20MySQL%20Database.md https://www.slideshare.net/MariaDB/mariadb-high-availability-81651161
:
Bearbeitet durch User
Das Problem bei Cluster Lösungen ist der Administrationsaufwand.....kein normaler IT support kann soetwas wieder in Betrieb nehmen nach zB einem Stromausfall....außerdem braucht es bei Multisynchronen Setups min. 5HW Nodes...das ist wahrscheinlich weit von dem entfernt was der TO möchte.. @TO bleib bei deinem Setup und fertige eine Doku an wie man das Backup einspielt. Dann such dir eine fähige IT Firma für den Notfall..das ist der einzig gangbare Weg - alles andere übersteigt deine Ressourcen bei weitem
Snapshots wären auch eine Lösung. Wenn der DB Server ausfällt, einfach ein älteres Snapshot wiederherstellen. Die Snapshots kann man auch in Intervallen automatisiert neu anlegen lassen. Einen Datenverlust wird man in dem Fall aber dennoch haben, da ein Snapshot genau wie ein Backup auch, nur einen älteren Zustand der Datenbank wiederherstellen würde. Will man neu hinzukommende Daten sichern, dann muss man bevor man zu einem älteren Sanpshot zurückgeht, die irgendwie wegsichern und dann manuell einpflegen. Für Snapshots eignet sich ein Dateisystem wie ZFS.
Nano schrieb: > Snapshots wären auch eine Lösung. Wie man ohne IT Kompetenz kaputte Hardware mit Snapshots wieder ganz macht, wäre dann aber noch zu klären.
> wäre dann aber noch zu klären.
Die Entwicklung der vergangenen Jahrzehnten ist total in die falsche
Richtung gegangen. Wir haben tolle Cluster-Systeme, die niemand mehr
korrekt konfigurieren und hochfahren kann.
Besser wäre, die Backup-Mechanismen stellen einfach eine konsistente
Festplatte mit Betriebssystem, Programmen und aktuellen Daten zusammen.
Wenn der Rechner nicht mehr funktioniert, einfach Platte raus ziehen und
Backup-Platte rein schieben.
Keep it simple and stupid schrieb: > Besser wäre, die Backup-Mechanismen stellen einfach eine konsistente > Festplatte mit Betriebssystem, Programmen und aktuellen Daten zusammen. > Wenn der Rechner nicht mehr funktioniert, einfach Platte raus ziehen und > Backup-Platte rein schieben. Nutzt aber nix, wenn der Fehler jenseits der Software oder Festplatte liegt...
Keep it simple and stupid schrieb: > Die Entwicklung der vergangenen Jahrzehnten ist total in die falsche > Richtung gegangen. Wir haben tolle Cluster-Systeme, die niemand mehr > korrekt konfigurieren und hochfahren kann. Ach? Tatsächlich hat sich die Sache in der betrieblichen Praxis wesentlich vereinfacht. Etliche Cluster von PC-Servern wurden durch Virtualisierung abgelöst. Redundante VM-Hosts ersetzen diverse Individuallösungen früherer ressourcenfressender Hardware-Cluster. Viel Knowhow braucht das nicht - beim Storage-Cluster evtl schon, aber das brauchte man vorher auch schon. (1) In vielen Fällen reicht es bereits aus, wenn beim Crash eines Hosts die VMs auf den anderen Hosts neu gestartet werden. Der Service ist wenige Minuten weg und muss dafür nur aus einem VM-Crash heraus neu starten können. Spart zudem an Lizenzen und redundanter Hardware. (2) Reicht das nicht, kann man einen sekundären Server als permanent bzgl RAM synchronisiertes Replikat auf einem anderen Host betreiben. Fliegt der Host des ersten weg, übernimmt das Replikat fliegend. In einer solchen Umgebung sind automatisch alle Server durch (1) gegen HW-Ausfall abgedeckt, ein paar besonders zeitkritische evtl durch (2). Egal was für Server das sind, mit egal welchem Betriebssystem. Ein Knowhow für alles. Unabhängig davon gibt es weiterhin recht umgängliche Lösungen innerhalb der Applications. MySQL/MariaDB Varianten wurden bereits genannt. Microsoft Exchange repliziert die DB selbst, Active Directory und DHCP ebenso.
:
Bearbeitet durch User
A. K. schrieb: > Nano schrieb: >> Snapshots wären auch eine Lösung. > > Wie man ohne IT Kompetenz kaputte Hardware mit Snapshots wieder ganz > macht, wäre dann aber noch zu klären. Ah sorry, habe das gestern Nacht nicht richtig gelesen. Dachte es ging nur um den Datenbankserver wenn dieser als Software Probleme macht. Wenn die HW ausfällt, dann ist das natürlich nicht mehr so einfach. Aber hier könnte man die Snapshots auf einem NAS machen. Den Datenbankserver auf eigener HW und die Daten kann man dann per nfs einbinden oder kopieren. Fällt der erste DBS aus, dann könnte ein anderer einspringen und die Daten vom NAS per nfs einbinden. Falls die Daten auf dem NAS wegen dem ersten DBS kaputt sind, kommt der Snapshot ins Spiel. Das ganze ist natürlich etwas komplizierter und es bräuchte wirklich einen Admin, der erst einmal analysisert, was genau kaputt ist. Umsonst gibt es da nichts. Insofern, wie wäre es mit ssh und Remoteadministration wenn man vor Ort nicht da sein kann?
Nano schrieb: > Wenn die HW ausfällt, dann ist das natürlich nicht mehr so einfach. > Aber hier könnte man die Snapshots auf einem NAS machen. Damit verschiebst du die Verfügbarkeitsfrage vom DB-Server auf ein hochverfügbares NAS. Mal ehrlich: Ist das einfacher als eine simple MariaDB-Replikation? Die hatte ich schon. Ist nicht weiter kompliziert und x-fach beschrieben. Der Fallback geht halt nur offline, weil dabei ein Backup der Slave-DB zurück kopiert werden muss, aber 200 MB sind Pillepalle. > Das ganze ist natürlich etwas komplizierter und es bräuchte wirklich > einen Admin, der erst einmal analysisert, was genau kaputt ist. > Umsonst gibt es da nichts. Exakt. Also nix für die Hauskatze. Die ist aber Vorgabe. Bei der vorgeschlagenen Replikation muss man nur die IP-Adresse der Funktion übernehmen. Was manuell problemlos ist, weil man split brain nicht berücksichtigen muss, sondern ganz banal auf STONITH per Hauskatze setzt. Wenn man sich die DB zerlegt hat und deshalb nichts mehr geht, dann hilft das natürlich nicht. Aber dafür einen katzentauglichen Weg zu finden, ohne sich der konkreten Anwendung zu nähern, dürfte im privaten Umfeld schwierig sein.
:
Bearbeitet durch User
A. K. schrieb: > Nano schrieb: >> Wenn die HW ausfällt, dann ist das natürlich nicht mehr so einfach. >> Aber hier könnte man die Snapshots auf einem NAS machen. > > Damit verschiebst du die Verfügbarkeitsfrage vom DB-Server auf ein > hochverfügbares NAS. Ja, das ist richtig. Man müsste noch Redundanz einbauen und zwei NAS vorhalten. Dann kann man sowohl HW Fehler als auch Softwarefehler schnell ausgleichen. Aber die Analyse gehört trotzdem dazu, denn man muss ja wissen, wenn etwas mit der Software schief läuft, nicht das man mit kaputten Daten weiterarbeitet. Durch die redundante HW wäre es aber zumindest administrativ per remote Zugang lösbar. > > Mal ehrlich: Ist das einfacher als eine simple MariaDB-Replikation? Die > hatte ich schon. Ist nicht weiter kompliziert und x-fach beschrieben. > Der Fallback geht halt nur offline, weil dabei ein Backup der Slave-DB > zurück kopiert werden muss, aber 200 MB sind Pillepalle. Backups haben halt das Problem, dass sie vielleicht nicht regelmäßig gemacht werden, dann hat man einen sehr alten Datenbestand der Datenbank. Die Snapshots lassen sich automatisieren und bspw. auch stündlich machen. Die Backups nur, wenn man die HW nicht abklemmt, aber dann ist das kein Backup mehr, da ein Backup streng genommen erst dann ein Backup ist, wenn im Falle eines Befalls von Schadsoftware des Servers das Backup davon nicht betroffen ist, also abgeklemmt wurde. Eine Platte die dauerhaft dranhängt, selbst wenn sie die Daten spiegelt, kann somit kein Backup sein. Im Prinzip hat man dann damit dann sowieso so etwas wie ein NAS, nur eben in billig. Insofern kann man auch gleich zwei externe NAS nehmen und Snapshots nutzen. Backups ersetzen die allerdings auch nicht, aber ein Großteil der Crashszenarien wie HW Ausfall usw. kann man damit abdecken. Das Zurückspielen aus einem Backup ist einfach, da stimme ich zu.
Nano schrieb: > Das Zurückspielen aus einem Backup ist einfach, da stimme ich zu. Kommt drauf an, ob man Ahnung hat, es an die richtige Stelle spielt UND es aktuell genug ist. Die Messwerte von Weihnachten bis heute könnten z.B. schon fehlen?
Nano schrieb: >> Mal ehrlich: Ist das einfacher als eine simple MariaDB-Replikation? Die > > Backups haben halt das Problem, Diese Replikation hat im Betrieb nichts mit einem Backup zu tun. Der Master liefert dem Slave (in der ursprünglichen Version) permanent und live alle relevanten SQL Statements, und der vollzieht sie ebenso live auf seiner eigenen DB nach. Einen Backup - was dann auch eine offline Kopie des Filesystems sein kann - braucht man nur beim Fallback, also zurück von Slave auf Master. Und bei der Einrichtung der Replikation. Nebenbei: Einen Bezug zum Backup gibts nur andersrum: Dieser Replikations-Mechanismus wird ggf auch für point in time recovery verwendet. Man hebt die binlogs dieses Verfahrens seit der letzten Vollsicherung auf. Vollsicherung plus binlogs = letzter Stand.
:
Bearbeitet durch User
Eine automatische Verifikation der Replikation ist einfach: Man setzt einen Query sowohl auf den Master als auch auf den Slave ab (über die Node-IP vom Slave statt der Funktions-IP) und erfragt irgendeinen Wert, der den letzten Stand des Inhalts beschreibt. Idealerweise ist das eine Timestamp. Liegen die mehr als ein paar Sekunden auseinander, könnte man ein Problem haben.
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.