MySQL Replikation

[[monk]]

Hallöchen,

ich befasse mich derzeit mit der Backupmöglichkeit eines MySQL Servers.
Allerdings konnte ich die etwas schwammigen Formulierungen auf mysql.com nicht ganz verarbeiten.

Konkret habe ich nicht kapiert ob die Replizierung in gewissen Zeitabständen erfolgt, oder nach jedem SQL Query.

Wenn es nach jedem Query passiert, so sind die daten ja immer nahezu 100%ig identisch. Man könnte also eine subdomain ala sql.meinedomain.de anlegen und alle Connections drauf laufen lassen. Ein Script prüft jede minute ob der Datenbankserver noch richtig arbeitet, wenn nicht, ändert das Script den DNS auf den Slave - Datenbankserver.

Würde diese Art von Ausfallsicherheit funktionieren ?
Oder gibt es bessere Lösungen dafür?

Das Prinzip ist im Grunde genommen von mysql.com abgeschaut, allerdings frage ich mich, was passiert, wenn der Master ausfällt und dann Query´s mit Datenänderungen auf dem Slave auflaufen.

Das Script müsste ja dann theoretisch auf dem Slave "Stop Slave" ausführen und den Slave dann zum Master machen. Der eigentliche Master müsste derweil als Slave konfiguriert werden.
Wenn dann der ehemalige Master hochkommt synchronisiert er sich automatisch mit dem anderen Server

Ich beschäftige mich damit, weil ich mit dem Gedanken spiele, postfix, proftpd und andere Dienste direkt über die Datenbank laufen zu lassen.
Und nachdem hier ein Hohes Risiko entsteht, was den Ausfall betrifft, wollte ich damit vorbeugen.


Gruß

Michael

[dea]

Ganz wertneutral: Nimm eine andere Datenbank. Wenn Du schon über verteilte Replikationen nachdenkst bist Du mit MySQL nicht gut bedient, eher wären SAPDB (ich glaub' die heist jetzt MaxDB) oder postgres geeignet, da hier die entsprechenden Methoden von Beginn an resp. seit vielen Jahren implementiert sind.

Grundsätzlich sollten die von Dir angesprochenen Problemstellungen hinreichend durch das RDBMS Deiner Wahl behandelt werden, wenn Du Dir dann aber auch noch über die generelle Verfügbarkeit der DB resp. den aus der Replikation erwachsenden Konsequenzen den Kopf zerbrichst empfehle ich Dir, Dich mit der Idee, einen LDAP-Server "dazwischenzuschalten", zu befassen.

Ansonsten nur noch der leise Hinweis: Replikation ist nicht gleichbedeutend mit Hochverfügbarkeit! Für HA müssen weitere Kriterien erfüllt sein - und das was Du zu suchen scheinst ist Hochverfügbarkeit ...

Ganz nett, bei Google gefunden:

Web Definition: replication - The process of duplicating server shares and database objects (usually tables) in more than one location, including a method of periodically rationalizing (synchronizing) updates to the objects. Database replication is an alternative to the two-phase commit process. Microsoft SQL Server 6+ supports replication of databases across multiple Windows NT servers. Updating Windows NT Backup Domain Controllers (BDCs) from a Primary Domain Controller (PDC) occurs by replication of the Security Accounts Manger (SAM) database.
http://www.pace.ch/cours/glossary.htm

Siehe auch http://www.google.com/search?q=define:replication

Und zu HA:

The ability of a resource to withstand a hardware or software failure. High availability is achieved by using some form of resource duplication that removes single points of failure. Availability also is measured by a resource's reliability. No resource can be protected against an infinite number of failures.
h30097.www3.hp.com/docs/base_doc/DOCUMENTATION/V50_HTML/ARH9GATE/GLSSRYXX.HTM

Gefunden in http://www.google.com/search?q=define:high+availability

[majortermi]

SAPDB kennt keine Replikation sondern nur Hot-Standby (läuft aber für die meisten Zwecke auf da gleiche hinaus). Dafür ist SAPDB ziemlich unschön zu konfigurieren - ich habe es bislang unter Linux nicht zum Laufen bekommen, obwohl ich exakt nach der Anleitung in einem Buch vorgegangen bin. Anscheinend hat es von Version 7.4 zu Version 7.5 z.T. recht drastische Ã?nderungen gegeben.

PostgreSQL kennt AFAIK weder Replikation noch Hot-Standby. Eine recht einfache Replikationsmöglichkeit bietet - bitte nicht hauen - Microsoft SQL Server 2000.

Ansonsten kommen natürlich noch die "großen", also Oracle, DB2 und Sybase in Frage.

[dea]

SAPDB kennt keine Replikation sondern nur Hot-Standby (läuft aber für die meisten Zwecke auf da gleiche hinaus). Dafür ist SAPDB ziemlich unschön zu konfigurieren - ich habe es bislang unter Linux nicht zum Laufen bekommen, obwohl ich exakt nach der Anleitung in einem Buch vorgegangen bin. Anscheinend hat es von Version 7.4 zu Version 7.5 z.T. recht drastische Ã?nderungen gegeben.

PostgreSQL kennt AFAIK weder Replikation noch Hot-Standby. Eine recht einfache Replikationsmöglichkeit bietet - bitte nicht hauen - Microsoft SQL Server 2000.

Ansonsten kommen natürlich noch die "großen", also Oracle, DB2 und Sybase in Frage.

*BANG* Also für diesen Post gehörst Du doch geprügelt (arme Forelle, aber es muss sein *fg*)

pd und Replikation:

zum einen http://gborg.postgresql.org/project/pgr ... isplay.php und zum anderen .. find' ich nicht mehr, es gab' aber mal einen Guide wie man etwas vergleichbares mit Hausmitteln hinbekommt.

MS SQL Server auf 'nem *NIX, das möchte ich erst einmal sehen. Auch ist deren "Replikation" in Abhängigkeit zur Anzahl der Datensätze unzuverlässig.

SAPDB - Tja, die Bücher sind naturgemäß langsamer als die Entwicklung in RL ;) Und bitte erklär' mir mal, warum Deiner Meinung nach, Hot-StandBy ohne Replikation stattfinden soll/kann. Eher dürfte (aus rein technischer Sicht) eine SAPDB/Hot-StandBy Lösung den Anforderungen des OP am ehesten genügen. Wenn Du ihr noch einmal eine chance geben willst: Google, es gibt mittlerweile brauchbare elektr. Guides und HOWTOs dazu ;)

Die "großen" RDBMSe (Oracle, IBM) hatte ich außer Acht gelassen, da ich davon ausgehe, dass es hier um eine Lösung mit möglichts geringen Anschaffungskosten geht.

Noch ein Wort an die Adresse des OP: Sollte es wirklich Replikation gewesen sein (und nicht HA), dann schau' Dir die Möglichkeiten des Exports/Dumps des RDBMS Deiner Wahl an. Die "großen" verwenden nämlich ausschließlich diesen Mechanismus für eine saubere Daten- und Bewegungsreplikation. Dabei wird die "Live"-DB gedumpt, je nach Fähigkeit des RDBMS existieren bereits Transaktions- und Redo-Logs, die Dumps zur "StandBy"-DB transportiert und dort nachgefahren. Zusätzlich gehen viele Anwender noch her und sichern die Dumps, insbesondere, wenn es sich um Transaktions- bzw. Redo-Logs handelt.

Replikation à la M$ (und wohl auch MySQL) mit einem 64-Bit Integer ist unzuverlässig und fehleranfällig, da je nach Anwendung jeder Datensatz bzw. jede Transaktion einen Wert "verschlingt". Handelt es sich um eine große DB mit vielen Ã?nderungen kann es sehr schnel passieren, dass die Zähler umschlagen was wiederum zusätzliche Probleme verursachen kann (bei postgres ist dies recht gut dokumentiert und erläutert).

[majortermi]

*BANG* Also für diesen Post gehörst Du doch geprügelt (arme Forelle, aber es muss sein *fg*)

pd und Replikation:

zum einen http://gborg.postgresql.org/project/pgr ... isplay.php und zum anderen .. find' ich nicht mehr, es gab' aber mal einen Guide wie man etwas vergleichbares mit Hausmitteln hinbekommt.

Aber von Haus aus unterstützt PostgreSQL meines Wissens keine Replikation. Zumindest konnte ich, als ich das letzte mal nachgeschaut habe, in der offiziellen Dokumentation nichts dazu finden.

MS SQL Server auf 'nem *NIX, das möchte ich erst einmal sehen. Auch ist deren "Replikation" in Abhängigkeit zur Anzahl der Datensätze unzuverlässig.

Auf *NIX benutzt man eben Sybase. Die Verwandschaft zwischen Sybase und MS SQL-Server ist doch recht groß.

SAPDB - Tja, die Bücher sind naturgemäß langsamer als die Entwicklung in RL ;) Und bitte erklär' mir mal, warum Deiner Meinung nach, Hot-StandBy ohne Replikation stattfinden soll/kann. Eher dürfte (aus rein technischer Sicht) eine SAPDB/Hot-StandBy Lösung den Anforderungen des OP am ehesten genügen.

Entschuldige es bitte, wenn ich falsch liege. Für mir ist der Unterschied zwischen Hot-Standby und Replikation, dass bei Hot-Standby im Normalbetrieb alle Zugriffe immer auf den Hauptserver erfolgen, bei Replikation hingegen ist es möglich, die Requests auf mehrere Server aufzuteilen. Letzteres ist natürlich für HA völlig uninteressant und nur zur Skarlierbarkeit von Interesse.

Replikation à la M$ (und wohl auch MySQL) mit einem 64-Bit Integer ist unzuverlässig und fehleranfällig, da je nach Anwendung jeder Datensatz bzw. jede Transaktion einen Wert "verschlingt". Handelt es sich um eine große DB mit vielen Ã?nderungen kann es sehr schnel passieren, dass die Zähler umschlagen was wiederum zusätzliche Probleme verursachen kann (bei postgres ist dies recht gut dokumentiert und erläutert).

Hm, mal rechnen: Nehmen wir mal an, dass die Datenbank 4096 Requests pro Sekunden bekommt. Dann reicht eine 64-Bit-Integer immerhin etwa 142 808 207 Jahre.

[dea]

Also zuerst zur Replikation:

a redundant component in a fault tolerant storage system that has power applied and is ready to operate, but which does not perform its task as long as the primary component for which it is standing by is functioning properly.
http://www.storage.ibm.com/glossary.htm

Aber von Haus aus unterstützt PostgreSQL meines Wissens keine Replikation. Zumindest konnte ich, als ich das letzte mal nachgeschaut habe, in der offiziellen Dokumentation nichts dazu finden.

Ist doch uninteressant, ob pg "von Haus aus" repliizieren kann oder ob dafür ein (OSS) Modul eingesetzt werden kann. Wenn ich die Seite wiederfinde poste ich die URL. Es funktioniert mit der "traditionellen" Replikation mittels Dumps/Logs.

Die Verwandschaft zwischen Sybase und MS SQL-Server ist doch recht groß.

Du sagst es ... *hrhrhr*

Entschuldige es bitte, wenn ich falsch liege. Für mir ist der Unterschied zwischen Hot-Standby und Replikation, dass bei Hot-Standby im Normalbetrieb alle Zugriffe immer auf den Hauptserver erfolgen, bei Replikation hingegen ist es möglich, die Requests auf mehrere Server aufzuteilen. Letzteres ist natürlich für HA völlig uninteressant und nur zur Skarlierbarkeit von Interesse.

Vollkommen daneben. Aber sowas von daneben. In der "großen" DB-Welt bezeichnet Hot-Standby ein Verfahren, sämtliche (!!) Transaktionen der Live-DB (erzwungenermaßen mit Offset) auf der StandBy-DB nachzuspielen. Fällt dann das Live-System aus muss "nur noch" dafür gesorgt werden, dass die StandBy-DB die Arbeit übernimmt. Je nach akuter Last gehen dabei natrlich eine Reihe von Transaktionen kaputt. Das macht i.d.R aber nur den Anwendungsentwikcklern Kopfschmerzen. Aber dafür werden die ja bezahlt - hehe ;)

Replikation (siehe Definition weiter oben) hat nullkommagarnichts mit Lastverteilung zu tun, dafür ist "Clustering" zuständig. Lies' Dir die Doku zu Ora10g oder zum RAC aus dem gleichen Haus durch, da geht es u.a. um die hier besprochenen Themen Lastverteilung, Hochverfügbarkeit und Replikation von Datenbanken.

Hm, mal rechnen: Nehmen wir mal an, dass die Datenbank 4096 Requests pro Sekunden bekommt. Dann reicht eine 64-Bit-Integer immerhin etwa 142 808 207 Jahre.

Und was ist mit den Datensätzen, den Transaktionen (Transaktion != Request), usw? ;)

[[monk]]

danke für die antworten.

Ein HA-System hab ich nicht vor. (Sonst würde ich größere Datenbanksysteme verwenden). Es sollte eigentlich nur einen totalausfall vermeiden. Falls z.B. mal was beim MySQL - Server update schiefgehen sollte, darf halt nicht den ganzen Tag alles down sein. Die anderen Datenbanken können ruhig für ein zwei stunden oder so down sein, nur die ganzen anderen Sachen sollten weiterlaufen.

Aber das MaxDB Zeugs sieht gut aus.

Nur lohnt es sich glaube ich nicht, MaxDB zum MySQL server zusätzlich laufen zu lassen. Währe MaxDB gleich ansteuerbar wie MySQL (bzw. MySQL mit den Funktionen von MaxDB), dann würde ich prompt MySQL durch MaxDB ersetzen..


Gruß

Michael

[dea]

Ein HA-System hab ich nicht vor. (Sonst würde ich größere Datenbanksysteme verwenden).

Was hat denn die "Größe" von RDBMSen mit Hochverfügbarkeit zu tun?

Es sollte eigentlich nur einen totalausfall vermeiden. Falls z.B. mal was beim MySQL - Server update schiefgehen sollte, darf halt nicht den ganzen Tag alles down sein. Die anderen Datenbanken können ruhig für ein zwei stunden oder so down sein, nur die ganzen anderen Sachen sollten weiterlaufen.

Auch das ist Hochverfügbarkeit. Wenn Dir eine längere Ausfallzeit, hier 2 - 4 Stunden, akzeptabel erscheint, kannst Du es auch mit "Cold-Standby" versuchen. Funktioniert ähnlich wie Hot-Standby, allerdings liest hier die Standby-DB die Transaktionen nicht fortlaufend, sondern im Batch-Modus (also beispielsweise per Cron gesteuert) ein. So in etwa:

Live-DB -> Dump -> Transport zum Standby -> Sammeln der Dumps auf dem Standby -> Periodisches Einlesen der gesammelten Dumps in die StandBy-DB.

Das sollte auch in MySQL gehen. Vorteil gegenüber der Replikation: Du kannst Die Dumps archivieren und so die DB (zumindest theoretisch, so lange Du es noch nicht ausprobiert hast) gezielt auf einen bestimmten "Stand" zurückfahren.

Nur lohnt es sich glaube ich nicht, MaxDB zum MySQL server zusätzlich laufen zu lassen. Währe MaxDB gleich ansteuerbar wie MySQL (bzw. MySQL mit den Funktionen von MaxDB), dann würde ich prompt MySQL durch MaxDB ersetzen..

ODBC? PHP? Perl::DBI? Python? Alles da ... ;)

Aber wenn Deine MySQL läuft und Du damit klar kommst ... Wenn Du dann auch noch die gewünschte Verfügbarkeit einrichten kannst besteht eigentlich ken Grund für einen Wechsel.

[[monk]]

Na ja bei größeren Systemen kommt es ja meißt auf die Ausfallsicherheit an.
Ich kenn zumindest kein "großes" Datenbanksystem, dass eine schlechte Ausfallsicherheit hat.

DB2 z.b. (wobei mir DB2 zuviel Einschränkungen hat, was das SQL angeht)


Mit gleich ansteuerbar meinte ich dass man z.b. über phpMyAdmin drauf zugreifen kann =)

Soweit ich das gesehen hab, kann man die MaxDB von PHP aus nur über ODBC ansprechen.
Was zwar nicht weiter tragisch währe aber nur aus dem grund eine umrüstung währe quatsch =)

Was mir noch so einviel ist eine art Proxy, dass alle Query´s abfängt und an beide Server weiterleitet und dann je nach status, die informationen von einem der zwei servern holt.

Währe halt eine kleine Performance-Bremse.

Aber danke die idee mit dem dump ist auch nicht schlecht. da könnte man den dump sogar direkt per ssh auf dem slave ausgeben lassen.

Gruß

Michael

[majortermi]

Replikation (siehe Definition weiter oben) hat nullkommagarnichts mit Lastverteilung zu tun, dafür ist "Clustering" zuständig. Lies' Dir die Doku zu Ora10g oder zum RAC aus dem gleichen Haus durch, da geht es u.a. um die hier besprochenen Themen Lastverteilung, Hochverfügbarkeit und Replikation von Datenbanken.

Vielen Dank für die Information. Dann war das in einem Buch, das ich mal gelesen habe, völlig falsch definiert.

[dea]

Replikation (siehe Definition weiter oben) hat nullkommagarnichts mit Lastverteilung zu tun, dafür ist "Clustering" zuständig. Lies' Dir die Doku zu Ora10g oder zum RAC aus dem gleichen Haus durch, da geht es u.a. um die hier besprochenen Themen Lastverteilung, Hochverfügbarkeit und Replikation von Datenbanken.

Vielen Dank für die Information. Dann war das in einem Buch, das ich mal gelesen habe, völlig falsch definiert.

Komisches Buch, eigentlich ist der Unterschied augenscheinlich ...

Replikation (Beispiel 1): Lotus Notes/Domino. Datensätze werden zwischen Client(s) und Server konsistent gehalten.

Replikation (Beispiel 2):
Lagerhaltung an X Standorten. Vor Ort eigenständige Infrastruktur. Verwaltung zentral. Damit die die zentral ermittelten Kommissionslisten in den Standorten ausgedruckt werden können, müssen die entsprechenénden Tabellen(teile) zu den Lager-DBen repliziert werden. Damit die Kommi-Listen zentral ermittelt werdne können (und der Einkauf neue Ware ordern kann, usw. usf.) müssen die Lager-DBen zur zentralen DB repliziert werden. In diesem Beispiel ist es aber vollkommen uninteressant, die Belastung der DBen auf mehrere Hosts zu verteilen (eher hinderlich).

Lastverteilung/Load Balancing (Beispiel):

Online-Buchhandel. Hier werden (bei entsprechender Frequentierung) nicht nur die Webserver sondern auch den DB-Server geclustert. Damit wird erreicht, dass die Belastung einzelner Hosts eine kritische Marke nie erreicht oder überschreitet. Lustig ist dabei, insbesondere bei DBen, dass sich die "Wege" letztendlich wieder in einer einzelnen Datenbank-Instanz treffen ;)

[[monk]]

laut mysql.com ist das auch ein ding.
die machen aus dem replikationsthema auch eine last-verteilungs-lösung


Ich denke dass die Themen so dicht aneinander liegen, dass es nur noch feinheiten sind, die sich unterscheiden.

letzendlich haben beide oder mehrere server dieselbe daten. und von diesen sind sie auch abrufbar (sehr einfach gesehen *g*)


Gruß

Michael

[Anonymous]

hier ist die antwort auf die ursprüngliche frage:
http://www.phpbuilder.com/columns/tanov ... hp3?page=1
"Using MySQL's Built-In Replication"

hat mir sher geholfen...

2 tricks daraus:
- master-slave Beziehung basiert auf gegenseitigkeit ;) (damit ist der master nach seinem "wiederhochfahren" auch wieder up to date)
- INSERT und UPDATE querys werden im falle von der Verwendung als LOAD BALANCING nur auf dem Master ausgeführt, wenn der ausfällt, natürlich auch auf dem slave. (das vermeidet unterschiedliche datenstände)