8
Was ist die gescheiteste sql lösung für HA
Guten Tag,
Ich möchte nen kleines hosting aufbauen für ein Projekt.
2 LoadB.
2 FTP Server
2 Webserver
2 Mailserver
bis hierhin kein Problem!
zusätzlich kommt glusterfs ins spiel, auch kein Problem! (für zentrale konfigdatein)
Nun aber
ich möchten 2 sql nodes haben, welche immer den selben datenbestand haben (nicht replikation, oder master,master ?)
denn wenn auf sql-nodé1 eine neue db erstellt wird, soll diese auch auf dem 2. vorhanden sein.
ich dachte mir 2 sql installationen mit dem selben /var/lib/mysql folder auf dem glustersystem, aber da die daten und veränderungen im Speicher gehalten werden bin ich mir gerade unsicher.
Mysql cluster selbst funktioniert ja nur wenn ich die Datenbank auf beiden manuell anlege, aber es sollte alles autom. gehen. ?
(bin kein sql profi wenn was nicht stimmt bitte korrigieren)
Was würdet ihr empfehlen?
vielen Dank!
Ich möchte nen kleines hosting aufbauen für ein Projekt.
2 LoadB.
2 FTP Server
2 Webserver
2 Mailserver
bis hierhin kein Problem!
zusätzlich kommt glusterfs ins spiel, auch kein Problem! (für zentrale konfigdatein)
Nun aber
ich möchten 2 sql nodes haben, welche immer den selben datenbestand haben (nicht replikation, oder master,master ?)
denn wenn auf sql-nodé1 eine neue db erstellt wird, soll diese auch auf dem 2. vorhanden sein.
ich dachte mir 2 sql installationen mit dem selben /var/lib/mysql folder auf dem glustersystem, aber da die daten und veränderungen im Speicher gehalten werden bin ich mir gerade unsicher.
Mysql cluster selbst funktioniert ja nur wenn ich die Datenbank auf beiden manuell anlege, aber es sollte alles autom. gehen. ?
(bin kein sql profi wenn was nicht stimmt bitte korrigieren)
Was würdet ihr empfehlen?
vielen Dank!
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 145401
Url: https://administrator.de/forum/was-ist-die-gescheiteste-sql-loesung-fuer-ha-145401.html
Ausgedruckt am: 25.12.2024 um 15:12 Uhr
8 Kommentare
Neuester Kommentar
informier dich mal über PostGreSQL ... die haben jetzt in der neuen Version eine Art Synchronisation eingebaut (...) automatischer Abgleich der Datenbanken untereinander
Du kannst auch einen Microsoft Cluster bauen.
was man dazu braucht
2 oder Mehr Server 2003, 2008 oder 2008 R2
1 gemeinsamer iSCSI Storage
und 2 mal SQL Standart Lizenzen.
Kosten so gegen 80'000 Euro.
gruass affabanana..
PS:: Ist aber auch der E-mail Server redundat??
Oder der fileserver??? Oder die Netzwerkeinfrastruktur?????
Internetanschluss xDSL ????
Sonst bringt die redundante DB auch nicht viel.
was man dazu braucht
2 oder Mehr Server 2003, 2008 oder 2008 R2
1 gemeinsamer iSCSI Storage
und 2 mal SQL Standart Lizenzen.
Kosten so gegen 80'000 Euro.
gruass affabanana..
PS:: Ist aber auch der E-mail Server redundat??
Oder der fileserver??? Oder die Netzwerkeinfrastruktur?????
Internetanschluss xDSL ????
Sonst bringt die redundante DB auch nicht viel.
Hey,
ich gehe da lieber auf die Opensource branche
bin kein Fan von Microsoft, auser im Workstation bereich.
Danke trotzdem für die Info.
Es ist alles redundant und Highavaible, das einzigste was nicht im LPI Studium dabei war, war sql cluster
Hab mich schon mit postgre und Oracle in verbindung gesetzt.
muss mich mal näher den mysql Cluster mit ndb anschauen
greetz
ich gehe da lieber auf die Opensource branche
bin kein Fan von Microsoft, auser im Workstation bereich.
Danke trotzdem für die Info.
Es ist alles redundant und Highavaible, das einzigste was nicht im LPI Studium dabei war, war sql cluster
Hab mich schon mit postgre und Oracle in verbindung gesetzt.
muss mich mal näher den mysql Cluster mit ndb anschauen
greetz
Ähm - wo ist das Problem? Siehe z.B. http://www.howtoforge.com/loadbalanced_mysql_cluster_debian -> da kannst du dir nen Cluster mit sovielen MySQL-Nodes bauen wie du lustig bist... Ich hab selbst mal zum Spass einen gebaut (1 Mgmt-Node + 2 Nodes), geht recht simpel und läuft. Dafür braucht man nun wirklich kein MS oder sonstwas... ;)
Allerdings hat das ganze einen Nachteil: Wenn du das nachträglich aufbaust musst du die Tabellen noch einmal umformatieren und als Typ "NDB" festlegen. Die Sync läuft dann automatisch ab.
Schönen Gruß
Mike
Allerdings hat das ganze einen Nachteil: Wenn du das nachträglich aufbaust musst du die Tabellen noch einmal umformatieren und als Typ "NDB" festlegen. Die Sync läuft dann automatisch ab.
Schönen Gruß
Mike
Hallo maretz,
was ist jedoch wenn man nun für Kunden Datenbanken zur verfügung stellt und diese sollen myisam oder innodb sein ?
und :
Now we create the same database on sql2.example.com (yes, we still have to create it, but afterwards testtable and its data should be replicated to sql2.example.com because testtable uses ENGINE=NDBCLUSTER):
man muss diese auf beiden anlegen :/
ich würde gerne nen Clustered filsystem nehmen (glusterfsv3) und darauf die Datenbanken liegen haben, nur behält mysql die tabellen im chache und schreibt diese nicht direkt aufs storage, und informiert die nachbarn, sodass überall der selbe db bestand ist.
es sollte so wie bei groß isp´s aufgebaut sein nur wie :O(
das ist mein einzigstes Problem, welches ich noch nicht gefunden habe zu lösen :/
danke für deine Anteilnahme
was ist jedoch wenn man nun für Kunden Datenbanken zur verfügung stellt und diese sollen myisam oder innodb sein ?
und :
Now we create the same database on sql2.example.com (yes, we still have to create it, but afterwards testtable and its data should be replicated to sql2.example.com because testtable uses ENGINE=NDBCLUSTER):
man muss diese auf beiden anlegen :/
ich würde gerne nen Clustered filsystem nehmen (glusterfsv3) und darauf die Datenbanken liegen haben, nur behält mysql die tabellen im chache und schreibt diese nicht direkt aufs storage, und informiert die nachbarn, sodass überall der selbe db bestand ist.
es sollte so wie bei groß isp´s aufgebaut sein nur wie :O(
das ist mein einzigstes Problem, welches ich noch nicht gefunden habe zu lösen :/
danke für deine Anteilnahme
Moin,
also jetzt mal kurz langsam. Es ist die Frage was du willst. Entweder umsonst zum Spielen -> dann mit den Einschränkungen. Denn das ist gar nicht dafür gedacht das du diese DBs den Kunden zur Verfügung stellst sondern z.B. für eigene Projekte.
ODER du nimmst halt das was für ISPs usw. da ist (gibts eben als Windows-Cluster, oder eben von MySQL die spezielle Cluster-Version wie http://www.mysql.de/products/database/cluster/ ). Geht auch - da haust dann nen vernünftigen Load-Balancer davor -> feddich is die Laube. ALLERDINGS: Hier bewegst du dich schnell in Bereichen eines Mittel-Klasse-PKW und höher (ich kenne durchaus HA-Lösungen die im 6-Stelligen Bereich laufen - und da ist noch lange nicht das Ende der Fahnenstange!).
Was aber generell eine blöde Idee ist (egal welches DBMS du nutzt): Die Daten auf File-Ebene abgleichen zu lassen. Erstmal sollte jede gute DB die Daten im Cache behalten (die Suchzeit wäre auf der Platte einfach nur grottig!). Und dann würdest du dir noch ganz viele andere Sargnägel ins Boot hämmern. Nehmen wir an du hast 2 Server: DB1 und DB2. Du gleichst die beiden über nen Cluster-FS ab. Auf dem Server läuft ne Lager-DB. Jetzt geht Mitarbeiter 1 hin und trägst ins System ein "Kunde holt Ware ab". Gleichzeitig macht das auch Mitarbeiter 2 - nur der arbeitet auf DB2. Normalerweise würde eine Transaktion hier (bei einer guten Anwendung) das ganze verhindern -> solang MA1 an der Tabelle spielt darf MA2 nix ändern. Da du aber diesen Mechanismus erfolgreich umgangen hast weiss die DB1 nix von der Änderung bei DB2 und umgekehrt. Beide Datensätze sind frei. Jetzt syncst du die Dateien auf File-Ebene. Auch hier sagen beide DB-Systeme: "OK" -> weil ja nach dem Sync die Lager-DB für den Artikel um 1 reduziert ist. Für die Kunden-DB ist es auch ok -> bei 2 Kunden steht jetzt "Abgeholt" drin (oder - falls deine Sync doof läuft steht es nur bei einem Kunden drin - nur bei welchem ist dem Zufall überlassen).
Tja - nehmen wir an es handelt sich um das Lager von Teufel-Lautsprechern und ich bin Kunde 2. Ich komme ins Lager und möchte mein THX10-System abholen (würd ich gerne... nur fehlt das Kleingeld... aber das is ne andere Sache...). Ich steh vor dir und du erzählst mir "Nee, das kann ich nicht geben - das System sagt sie haben das schon abgeholt". Na - was meinst, bin ich glücklich das du ne HA-DB hast? Oder zieh ich dich danach so übern Tisch und hämmere deinen Kopf durch den Monitor? ;)
Also: Niemals am DBMS vorbei nur die Daten spiegeln. Schlechte Idee... Böse... nicht tun! Du umgehst damit wichtige Schutz-Funktionen - und im schlimmsten Fall hast du sogar am Ende gar nix mehr (weil eine geöffnete Datei z.B. nicht geschrieben werden darf - und leider war die Datei auf dem DB2-Server z.B. mal 5 Min. geöffnet... Irgendwo verschwinden jetzt definitiv einträge!). Das hat dann auch wenig mit nem Cluster zu tun - sondern mehr mit Harakiri!
Und für die Spielwiese reicht auch der o.a. Selbstbau-Cluster. Im produktiv-Betrieb würde ich auch da mindestens noch ein paar dinge dazu tun:
- 2ter Mgmt-Server falls der erste ausfällt -> is ja doof wenn du zwar nen HA-System mit 10 Nodes hast aber der Mgmt-Server weg ist... schon is essig.
- Loadbalancer für die Mgmt-Server (wenn beide laufen können die sich ja auch die Arbeit teilen... Da das Locking u. Transaktionen trotzdem laufen kein Thema)
- HeartBeat für die Überwachung der Server und ggf. die Alarm-Meldung an den Admin wenn einer Urlaub macht.
- Ggf. Managebare Steckdosen -> Meint ein Server das er nicht mehr reagiert dann diesen hart abschiessen (Strom abschalten!) -> und den Backup-Server auf dessen Adresse bringen.
Aber wie gesagt - ich würde bei einem richtigen Produktiv-Einsatz auch nicht unbedingt so eine Bastel-Lösung nehmen. Ist zwar günstiger - aber wenn man HA-Anforderungen hat dann ist das meistens dann der Fall wenn nen Ausfall richtig ins Geld geht (z.B. bei o.g. Lager-Beispiel kann es schnell mal sein das nen Ausfall für 5 - 10 Minuten zu ner komplett-Inventur führt). Da lohnt es sich dann häufig das man wirklich zertifizierte Systeme nimmt...
Was Kunden-Datenbanken bei nem ISP angeht: Hier ist dann die Frage was man will: Günstig ne DB anbieten? Dann gibts keinen Cluster - fertig! Oder der Kunde zahlt ein wenig -> dann muss es aber ne gute Lösung sein und kein selbstfrickeln... Der einzige Grund für die Frickel-Lösung: Man kann sich zum 0-Tarif eben mal mit der Materie beschäftigen und seine Erfahrungen sammeln...
also jetzt mal kurz langsam. Es ist die Frage was du willst. Entweder umsonst zum Spielen -> dann mit den Einschränkungen. Denn das ist gar nicht dafür gedacht das du diese DBs den Kunden zur Verfügung stellst sondern z.B. für eigene Projekte.
ODER du nimmst halt das was für ISPs usw. da ist (gibts eben als Windows-Cluster, oder eben von MySQL die spezielle Cluster-Version wie http://www.mysql.de/products/database/cluster/ ). Geht auch - da haust dann nen vernünftigen Load-Balancer davor -> feddich is die Laube. ALLERDINGS: Hier bewegst du dich schnell in Bereichen eines Mittel-Klasse-PKW und höher (ich kenne durchaus HA-Lösungen die im 6-Stelligen Bereich laufen - und da ist noch lange nicht das Ende der Fahnenstange!).
Was aber generell eine blöde Idee ist (egal welches DBMS du nutzt): Die Daten auf File-Ebene abgleichen zu lassen. Erstmal sollte jede gute DB die Daten im Cache behalten (die Suchzeit wäre auf der Platte einfach nur grottig!). Und dann würdest du dir noch ganz viele andere Sargnägel ins Boot hämmern. Nehmen wir an du hast 2 Server: DB1 und DB2. Du gleichst die beiden über nen Cluster-FS ab. Auf dem Server läuft ne Lager-DB. Jetzt geht Mitarbeiter 1 hin und trägst ins System ein "Kunde holt Ware ab". Gleichzeitig macht das auch Mitarbeiter 2 - nur der arbeitet auf DB2. Normalerweise würde eine Transaktion hier (bei einer guten Anwendung) das ganze verhindern -> solang MA1 an der Tabelle spielt darf MA2 nix ändern. Da du aber diesen Mechanismus erfolgreich umgangen hast weiss die DB1 nix von der Änderung bei DB2 und umgekehrt. Beide Datensätze sind frei. Jetzt syncst du die Dateien auf File-Ebene. Auch hier sagen beide DB-Systeme: "OK" -> weil ja nach dem Sync die Lager-DB für den Artikel um 1 reduziert ist. Für die Kunden-DB ist es auch ok -> bei 2 Kunden steht jetzt "Abgeholt" drin (oder - falls deine Sync doof läuft steht es nur bei einem Kunden drin - nur bei welchem ist dem Zufall überlassen).
Tja - nehmen wir an es handelt sich um das Lager von Teufel-Lautsprechern und ich bin Kunde 2. Ich komme ins Lager und möchte mein THX10-System abholen (würd ich gerne... nur fehlt das Kleingeld... aber das is ne andere Sache...). Ich steh vor dir und du erzählst mir "Nee, das kann ich nicht geben - das System sagt sie haben das schon abgeholt". Na - was meinst, bin ich glücklich das du ne HA-DB hast? Oder zieh ich dich danach so übern Tisch und hämmere deinen Kopf durch den Monitor? ;)
Also: Niemals am DBMS vorbei nur die Daten spiegeln. Schlechte Idee... Böse... nicht tun! Du umgehst damit wichtige Schutz-Funktionen - und im schlimmsten Fall hast du sogar am Ende gar nix mehr (weil eine geöffnete Datei z.B. nicht geschrieben werden darf - und leider war die Datei auf dem DB2-Server z.B. mal 5 Min. geöffnet... Irgendwo verschwinden jetzt definitiv einträge!). Das hat dann auch wenig mit nem Cluster zu tun - sondern mehr mit Harakiri!
Und für die Spielwiese reicht auch der o.a. Selbstbau-Cluster. Im produktiv-Betrieb würde ich auch da mindestens noch ein paar dinge dazu tun:
- 2ter Mgmt-Server falls der erste ausfällt -> is ja doof wenn du zwar nen HA-System mit 10 Nodes hast aber der Mgmt-Server weg ist... schon is essig.
- Loadbalancer für die Mgmt-Server (wenn beide laufen können die sich ja auch die Arbeit teilen... Da das Locking u. Transaktionen trotzdem laufen kein Thema)
- HeartBeat für die Überwachung der Server und ggf. die Alarm-Meldung an den Admin wenn einer Urlaub macht.
- Ggf. Managebare Steckdosen -> Meint ein Server das er nicht mehr reagiert dann diesen hart abschiessen (Strom abschalten!) -> und den Backup-Server auf dessen Adresse bringen.
Aber wie gesagt - ich würde bei einem richtigen Produktiv-Einsatz auch nicht unbedingt so eine Bastel-Lösung nehmen. Ist zwar günstiger - aber wenn man HA-Anforderungen hat dann ist das meistens dann der Fall wenn nen Ausfall richtig ins Geld geht (z.B. bei o.g. Lager-Beispiel kann es schnell mal sein das nen Ausfall für 5 - 10 Minuten zu ner komplett-Inventur führt). Da lohnt es sich dann häufig das man wirklich zertifizierte Systeme nimmt...
Was Kunden-Datenbanken bei nem ISP angeht: Hier ist dann die Frage was man will: Günstig ne DB anbieten? Dann gibts keinen Cluster - fertig! Oder der Kunde zahlt ein wenig -> dann muss es aber ne gute Lösung sein und kein selbstfrickeln... Der einzige Grund für die Frickel-Lösung: Man kann sich zum 0-Tarif eben mal mit der Materie beschäftigen und seine Erfahrungen sammeln...
hey, danke erstmal für die ausführliche Information!
jedoch folgendes, du schriebst:
ODER du nimmst halt das was für ISPs usw. da ist (gibts eben als Windows-Cluster, oder eben von MySQL die spezielle Cluster-Version wie http://www.mysql.de/products/database/clu ... )
jedoch kann man dort ja keine myisam oder innodb verwenden :/
aber der mysql cluster is kostenfrei
jedoch folgendes, du schriebst:
ODER du nimmst halt das was für ISPs usw. da ist (gibts eben als Windows-Cluster, oder eben von MySQL die spezielle Cluster-Version wie http://www.mysql.de/products/database/clu ... )
jedoch kann man dort ja keine myisam oder innodb verwenden :/
aber der mysql cluster is kostenfrei
