Registrierung
leer
leer
newposts
Users
search
FAQ
Login
Start

Hallo Gast, und Willkommen im Forum. Sie müssen sich einloggen oder registrieren, um alle Funktionen nutzen zu können.


PN's Forum \ Computer \ Programmierung \ Webentwicklung \ MySQL - Aufsetzen und Betrieb einer Master-Master Replikation


 Poison Nuke  *

#1 Verfasst am 18.09.2009, um 01:06:48



Hallo,

ich möchte euch hier im Thread vorstellen, wie eine MySQL Master-Master Replikation aufgesetzt wird, wie sie im laufenden Betrieb aussieht, wie sie am besten überwacht wird und wie man sich im Fehlerfalle am besten verhalten sollte.


Was ist eine Master-Master Replikation überhaupt?

Replikation bei MySQL bedeutet, es gibt zwei MySQL Server, einer ist der Master und einer ist der Slave. Der Master ist der eigentliche Server der alles ausführt und der Slave hält sich lediglich sekundenaktuell eine Kopie der Datenbank vor. D.h. sämtliche Änderungen an der Datenbank auf dem Master werden auch sofort an den Slave geschickt. Damit hat dieser immer exakt die gleiche Datenbank wie der Master. Ist vorallem im Bezug auf die Datensicherheit bei Ausfall von einem System von Vorteil aber weiterhin kann so auch die Leistung erhöht werden, da z.B. nur lesende SQL Zugriffe auch auf dem Slave ausgeführt werden können.
Allerdings hat so eine Master-Slave Replikation einen Nachteil: fällt der Master aus, ist normalerweise erstmal das ganze System offline. Man kann dann auf den Slave umschalten, damit dieser dann zum Master wird, allerdings ist hier eine kurze Ausfallzeit von wenigstens ein paar Minuten zu rechnen, jenachdem wie auf den SQL Server zugegriffen wird.

Bei einer Master-Master Replikation wird das ganze etwas weiter geführt. Grundlegend ist das Konzept gleich wie die Master-Slave Replikation...nur sie wird in beide Richtungen ausgeführt. D.h. beide Server sind Master und beide Server sind Slave. D.h. wenn ein Master eine Änderung hat dann schickt er sie auch gleich an den anderen Master und umgekehrt. Auf diese Weise können beide Systeme schreibenden Zugriff haben und sind dennoch immer auf dem gleichen Stand. Fällt einer der Master aus, läuft der andere weiter und es kommt zu keiner erkennbaren Ausfallzeit, da der andere ja bereits im Betrieb ist.


Wann wendet man eine Master-Master Replikation an und wann sollte man andere Strategien anwenden?

eine Master-Master Replikation ist nicht das Allheilmittel. Denn sie ist nicht unproblematisch. Der größte Problemfall ist der, das ein Master ein UPDATE Befehl ausführt, der auf einem vorhandenen Wert in der Datenbank aufbaut (ändere Wert x um einen bestimmten Betrag). Wenn nun der andere Master zur gleichen Zeit ebenfalls ein Update auf die gleiche Tabelle macht, dann wird bei der Replikation lediglich der Befehl des Updates geschickt. Es kommt nun dazu, dass das replizierte Update auf einem anderen Wert in der Tabelle basiert und damit am Ende ein anderes Ergebnis herauskommt. Die beiden Tabelle sind damit nicht mehr synchron. Für den sicheren Betrieb mit einer Master-Master Replikation sollte also eine Anwendung in Frage kommen wenn möglich gar keine UPDATES hat bei denen vorhandene Werte in der Datenbank als Basis für die Änderung genutzt werden. Besser wäre es dann wenn diese Werte vorher ausgelesen werden, die Rechnung von der FrontEnd Software ausgeführt werden und dann beim UPDATE ein absoluter Wert übergeben wird. Damit beugt man asynchronitäten vor.

Vorrangig ist die Master-Master Replikation dazu gedacht, um eine relativ kostengünstige Hochverfügbarkeitslösung aufzubauen. Denn man kann mit bereits zwei Server ein hochvergügbares System aufbauen.
Allerdings sollten es auch nicht mehr werden. Für ein ernsthaft größeres Projekt bei dem auch das Budget etwas höher ist sollte ein MySQL Cluster zum Einsatz kommen. Dies ist eine ganz andere Technologie, bei der mehrere Server über eine Clusterengine verbunden werden. Mehrere MySQL Server arbeiten wie ein großer Server mit hoher Redundanz. Allerdings sind hier mindestens 3 Server nötig um überhaupt einen lauffähigen MySQL Cluster zu erstellen...für einen sinnvollen Betrieb sind noch mehr Server nötig.

Die Master-Master Replikation hat allerdings noch einen weiteren Anwendungsfall:
geographische Redundanz.
Denn hochverfügbare System werden normalerweise über Loadbalancer mit virtuellen IPs angesprochen...d.h. zwei Server teilen sich eine IP. Dies ist allerdings nur innerhalb eines Rechenzentrums oder einer Domäne möglich. Wenn man eine geographische Redundanz haben will ohne merkbare Umschaltzeit (welche bei anderen Varianten teilweibe bis zu einer Stunde beträgt) dann wäre eine Master-Master Replikation auch hier das einzig sinnvolle. Wegen dem größeren Zeitversatz der Replikation aber auch nicht ganz unkritisch. Hier sollte sehr genau bekannt sein welche SQL befehle ausgeführt werden, um im vornherein Probleme durch eine Zeitdifferen auszugleichen.


Vorraussetzungen zum Aufsetzen einer Replikation

Ich gehe von zwei baugleichen Servern aus, da in den meisten Fällen eine Master-Master Konfiguration mit gleichzeitigem Webserver in einer DNS-Roundrobin Konfiguration genutzt wird. Da bei DNS Roundrobin die Zugriffe auf die Server fast exakt 50/50 erfolgen (in meiner Forenstatistik ist ein Punkt dabei "Master-Slave Ratio" da ist zu sehen wie das Verhältnis der Zugriff ist...bei einem mittlerweile bald 6-stelligen Wert seit der Erfassung an Zugriffen liegen fast genau 50% auf je einem der beiden Server) ist somit auch die Auslastung in den meisten Fällen ähnlich hoch.
Auf beiden Server läuft Debian Lenny, und MySQL Server und MySQL Client ist bereits installiert.

Eine weitere Netzwerkkarte für jeden Server wird nicht benötigt. Es könnte zwar auch ein internes Netzwerk verwendet werden, aber dies ist normalerweise unnötig bei einer solchen Anwendung, zumal dies bei einer geographischen Redundanz nur schwer umsetzbar wäre.


Anpassen der Konfigurationsdateien der beiden Server

Im folgenden ist der erste Masterserver "master" und der zweite "backup". So habe ich auch die beiden Server vom Forum benannt. Der zweite Server ist aus meiner Sichtweise das Backup. Auf diese Weise fällt es einfach sie zu unterscheiden. Man kann nat. auch mit Nummern arbeiten, wobei man hier leichter durcheinander kommen kann.

Als erstes benötigen wir auf jedem Server einen User, über den der jeweils andere Server zum replizieren zugreifen kann. Ich habe mich dafür entschieden, den User so zu nennen wie der zugreifende Host. Also ebenfalls "master" und "backup", man kann ihn aber auch beiden auch einfach "slave" oder so nennen. Wichtig ist, das man den Zugriff auf die IP von dem anderen Host begrenzt. Oder alternativ den Hostnamen. Nur die IP ist sicherer.

Quellcode
master-mysql> GRANT REPLICATION SLAVE ON *.* TO 'backup'@'87.118.122.4' IDENTIFIED BY 'passwort';

backup-mysql> GRANT REPLICATION SLAVE ON *.* TO 'master'@'87.118.122.38' IDENTIFIED BY 'passwort';



Danach muss die Konfiguration der MySQL Server angepasst werden. Dazu folgende Datei öffnen:

/etc/mysql/my.cnf

in beiden Dateien die Zeile

bind-address=127.0.0.1 mit einer Raute am Zeilenanfang (#) auskommentieren. Damit hört der mysqlserver auf allen Interfaces. Zum aktuellen Zeitpunkt (mysqld 5.5) ist es nicht möglich, mehr als eine Adresse anzugeben. Da man localhost benötigt, muss man für eine Replikation zwangsweise alle IPs freigeben, auch wenn man eine dedizierte Netzwerkverbindung dafür hat. Mittels IP-Tables lässt sich MySQL von extern allerdings sperren.

master:

Quellcode
[mysqld]

server-id               	= 1
replicate-same-server-id	= 0
auto-increment-increment	= 2
auto-increment-offset   	= 1

master-host     = backup.poisonnuke.de
master-user     = master
master-password = passwort
master-connect-retry    = 60
replicate-do-db = forum
binlog-do-db    = forum
slave-skip-errors = 1062

log-bin




backup:

Quellcode
[mysqld]

server-id               	= 2
replicate-same-server-id	= 0
auto-increment-increment	= 2
auto-increment-offset   	= 2

master-host     = master.poisonnuke.de
master-user     = backup
master-password = passwort
master-connect-retry    = 60
replicate-do-db = forum
binlog-do-db    = forum
slave-skip-errors = 1062

log-bin


Zur Erklärung der Paramter:

Server-ID muss ein eindeutiger Wert sein bei allen verbundenen Master-Slave Servern. Sollten zwei Slaves die gleiche ID haben und zum Master verbinden, dann gibt es auf einem der beiden Slaves massivste Probleme und die AUslastung vom Master und dem Slave steigt extrem an (und das Syslog füllt sich binnen Minuten um ein paar Megabyte).

auto-increment-increment -> ohne diese Option ist es reiner Zufall bis bei Autoincrement Feldern zwei Server gleichzeitig den gleichen Wert erzeugen und die Replikation wegen einem Fehler abbricht, bzw die Daten inkonstistent werden. Daher wird immer gleich um den Wert zwei vergrößert. Mit der nachfolgen Option sorgt dies dafür, das auto_increment Felder bei einem Server immer gerade, beim anderen Server immer ungerade Zahlen haben. Nur so wird eine Inkonsistenz effektiv verhindert

Die Optionen danach sollten klar sein. Die genannte Datenbank (replicate-do-db) ist in meinem Fall die Datenbank für das Forum...hier muss die zu replizierende Datenbank eingetragen werden.

Der Wert danach "slave-skip-errors" ist ein wenig kritisch. Dieser Wert sagt dem Slaveprozess von MySQL, dass er bei bestimmten Fehlern nicht abbricht. Ich habe hier den Wert "1062" eingetragen. Dieser Wert steht für "Duplicate Entry", d.h. bei einem INSERT sollte bei einem UNIQUE KEY Feld ein doppelter Wert eingetragen werden. Allerdings ist dies ab und an ein Bug von MySQL. Trotz korrekter Datenbank und Anwendung kommt es teilweise zu dem Fehler. Wenn die Datenbank und Anwendung allein niemals diesen Fehler produzieren könnte, dann sollte er gesetzt werden. Allerdings muss man vorsichtig mit der Verwendung sein. Weil wenn man einen Fehler im Quellcode hat dann kann diese Einstellung dazu führen, das die REplikation asynchron verläuft. Andererseits wenn die Replikation abbricht dann laufen die Server ebenfalls asynchron.


Nach dem Konfigurieren der my.cnf nun auf beiden Servern den MySQL Dienst neustarten. Noch passiert nichts. Jetzt auf beiden Server in den MySQL Client verbinden und in MySQL den Befehl

Quellcode
SLAVE STOP;

eingeben.

als nächstes wird auf dem Masterhost auf dem bisher die Datenbank gelaufen ist, diese gedumpt. Dazu gibt man zuerst auf dem Master in MySQL folgenden Befehl ein:

Quellcode
FLUSH TABLES WITH READ LOCK;

damit sind alle Tabellen gesperrt. Nun erstellt man einen MySQL-Dump.
Diesen Dump sollte man möglichst sicher aufbewahren, denn er stellt den aktuellen Start der Replikation dar.

Als nächstes gibt man auf dem Master im MySQL folgenden Befehl ein:

Quellcode
SHOW MASTER STATUS;

In der folgenden Ausgabe erhält man einen Dateinamen für die aktuelle Binäre Log-datei und einmal eine Zahl, die die aktuelle Position im binären Log darstellt. Diese beiden Werte sollte man am besten speichern, denn sie sind essentiell zum Start der Replikation.

die Tabellen auf dem Master kann man nun wieder freigeben mit

Quellcode
UNLOCK TABLES;


Den Dump kopiert man nun auf "backup". Dort spielt man den Dump zurück in die Datenbank ein. Nachdem dies geschehen ist, gibt man hier ebenfalls den Befehl "SHOW MASTER STATUS;" ein, und notiert sich hier auch die Datei und den aktuellen Wert (welcher durch den Dump wesentlich größer sein sollte als der Wert vom "master".

Als nächstes muss auf beiden Servern folgendes eingeben werden, ich schreibe für jeden Server eine extra Zeile. Bitte beachten, es muss bei den Daten für die Logposition genau das angegeben werden was bei SHOW MASTER STATUS ausgegeben wurde vom jeweils anderen Server. Hier auf keinen Falldurcheinander kommen.

Quellcode
master-mysql> CHANGE MASTER TO MASTER_HOST='backup.poisonnuke.de', MASTER_USER='master', MASTER_PASSWORD='passwort', MASTER_LOG_FILE='mysql-bin.0000xx', MASTER_LOG_POS=12345;
master-mysql> SLAVE START;

backup-mysql> CHANGE MASTER TO MASTER_HOST='master.poisonnuke.de', MASTER_USER='backup', MASTER_PASSWORD='passwort', MASTER_LOG_FILE='mysql-bin.0000xx', MASTER_LOG_POS=577345;
backup-mysql> SLAVE START;


direkt nach Ändernd er Parameter kann man nat. den Slaveprozess starten.
Wenn dies geschehen ist auf beiden Servern prüfen ob die Replikation funktioniert:

Quellcode
backup-mysql> SHOW SLAVE STATUS \G;
*************************** 1. row ***************************
             Slave_IO_State: Waiting for master to send event
                Master_Host: master.poisonnuke.de
                Master_User: backup
                Master_Port: 3306
              Connect_Retry: 60
            Master_Log_File: mysql-bin.000022
        Read_Master_Log_Pos: 78562662
             Relay_Log_File: slave-relay.000002
              Relay_Log_Pos: 172389
      Relay_Master_Log_File: mysql-bin.000022
           Slave_IO_Running: Yes
          Slave_SQL_Running: Yes
            Replicate_Do_DB: forum
        Replicate_Ignore_DB:
         Replicate_Do_Table:
     Replicate_Ignore_Table:
    Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
                 Last_Errno: 0
                 Last_Error:
               Skip_Counter: 0
        Exec_Master_Log_Pos: 78562662
            Relay_Log_Space: 172389
            Until_Condition: None
             Until_Log_File:
              Until_Log_Pos: 0
         Master_SSL_Allowed: No
         Master_SSL_CA_File:
         Master_SSL_CA_Path:
            Master_SSL_Cert:
          Master_SSL_Cipher:
             Master_SSL_Key:
      Seconds_Behind_Master: 0
1 row in set (0.00 sec)

ERROR:
No query specified 


wichtig ist hier "slave_IO_running". Dies muss auf Yes stehen. Steht dort ein No, dann hilft
/var/log/syslog

weiter. Dort steht drin, das z.B. der Port falsch ist, oder Passwort nicht stimmt beim Zugriff, oder der Host gar nicht erreichbar ist usw.
Wenn bei beiden Servern ein Yes steht, dann ist alles gut gelaufen und ab sofort befinden sich beide Server in einer Master-Master Replikation. Dies kann man auch direkt prüfen indem man einige Datensätze beim ersten Server hinzufügt und prüft ob diese auf dem zweiten Server ebenfalls angelegt wurden.



Betrieb einer Master-Master Replikation

Was ist im laufenden Betrieb zu beachten?
Man sollte vorsichtig sein was man macht. So eine Umgebung, wenn sie produktiv genutzt wird, sollte man nun erst recht nicht zum testen von Scripten nutzen. Denn verschiedene SQL Fehler durch falsche Scriptaufrufe oder so können die Replikation unterbrechen z.B.

Weiterhin sollte man IMMER darauf achten in welchem Status die Server sind. Wnen man z.b. geplante Wartungsarbeiten durchführt dann sollte immer von beiden Servern zuerst bei einem sämtliche Zugriffe beendert werden, damit nichts mehr in MySQL schreiben kann und dann muss auf beiden Server ein "SLAVE STOP" ausgeführt werden, damit es nicht zu fehlerhaften Synchronisierungen kommt.

Um zu prüfen, ob die Replikation bei beiden Server aktiv ist, bietet es sich an ein Prüfscript zu schreiben, das regelmäßig per Cron (alle 5min z.B.) aufgerufen wird.


ein ausführliches Überwachungsscript findet ihr in diesem Thread erklärt:
http://forum.poisonnuke.de/index.php?action=ViewThread&TID=5666







Was machen wenn die Replikation unterbrochen wird.

Wichtig ist zu schauen, ob die Replikation bei beiden abgebrochen ist oder nur auf einem. Wenn nur einer der beiden einen Replikationsfehler hat und der andere brav weitermacht, dann braucht man erstmal keinen "Stress" machen, denn es können grundlegend keine Daten verloren gehen. Als allererstes sollte man den nun nicht mehr replizierenden Slave von allen anderen Diensten her anhalten, das nichts mehr auf MySQL zugreifen kann. Danach auf dem aktiven Master die Replikation ebenfalls mit "SLAVE STOP" anhalten. Und dann vorallem schauen, was der Fehler war. Die MySQL Seite bietet zu den meisten Fehlern schon recht umfangreiche Hilfen an.
Die Inbetriebnahme der Replikation verläuft dann genauso wie im nächsten Abschnitt erklärt.

Sollte die Replikation auf beiden Servern unterbrochen werden, dann ist schnelles handeln angesagt, weil jetzt laufen die Datenbanken asynchron und es wird schwer diese wieder synchron zu bekommen. Man muss sich meist für eine von beiden entscheiden und die andere verwerfen. Daher bietet sich an so schnell wie möglich zu reagieren. Man könnte das oben gezeigte Script auch gleichzeitig die nötigen Schritt einleiten lassen, allerings ist das Problem, dass man genau prüfen muss was das Problem überhaupt ist. Denn die Replikation bricht ja auch ab wenn einer der Server ausfällt und dann wäre es sehr unpraktisch wenn der andere Master wegen einem Replikationsfehler auch den Dienst einstellt.
Hilfreich könnte hier auch das Tool "maatkit" sein (http://www.maatkit.org/), welches Werkzeuge zur Synchronisierung von Replikationsslaves bereithält, sowie Möglichkeiten die Replation erneut zu starten. Allerdings habe ihc es noch nicht ausprobiert, da die Replikation bisher problemfrei verlief.


Was macht man wenn einer der beiden Master-Server ausgefallen ist?
erstmal ruhig Blut. Der andere Server ist noch online und das Webprojekt damit nicht offline. Was man jetzt als erstes tun sollte, beim derzeit aktiven Master die Replikation anhalten. Danach startet man den zweiten Master, insofern das problemlos möglich ist, allerdings muss man dabei drauf achten, dass der zweite Server noch keine schreibenden MySQL Prozesse (Also meist Apache) startet. Denn nun muss man erstmal sehen das die Replikation zu dem Server erfolgreicht startet.
Sollte der Output von "SHOW SLAVE STATUS \G;" positiv ausfallen, dann kann man auf dem anderen Master mit SLAVE START die Replikation ebenfalls wieder starten. Erst wenn auch hier keine Fehler auftreten (am besten eine Weile laufen lassen und prüfen ob die Daten korrekt auf beiden Mastersystemen geschrieben werden), kann man dann auch wieder den Webserver starten damit die volle Redundanz wiederhersgestellt werden kann.

Wenn es nach dem hochfahren des ausgefallenden Servers dazu kommt, dass dieser sich nicht mehr mit dem Master verbinden kann (ERRNO = 2013), dann liegt dies oft an inkohärenten Binlogs. In dem Fall hilft es wenn man den letzten Dump bei dem der Master gestartet wurde in den Slave einspielt (wichtig, erneut folgenden Befehl eingeben:

Quellcode
CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.xxxxxx', MASTER_LOG_POS=#####;

hier die Daten eingeben die auch beim ersten starten des Slave eingegeben wurden.
Ganz wichtig: nun als allererstes ein "SHOW MASTER STATUS" ausführen auf dem inaktiven Server. Denn das CHANGE MASTER TO muss nun auch auf dem aktiven Server ausgeführt werden, da durch den Redump sich die binlogpositionen geändert haben.
Dann mit SLAVE START die Replikation auf dem ausgefallenden Server erneut starten. WICHTIG: bei dieser Aktion darf auf keinen Fall der Slaveprozess auf dem aktiven Master laufen. Wenn dies so ist zerstört man sich bei der Aktion die Datenbank...denn das einspielen des alten Dumps führt der Master ebenfalls aus und es entsteht ein Pingpong Effekt der ein pures Datenchaos binnen Sekunden erzeugt.
Wenn sich der Server alle Updates vom Master geholt hat, prüft man über SHOW SLAVE STATUS ob die Replikation erfolgreich läuft. Wenn dies so ist, startet man auch auf dem aktiven Server die Replikation wieder.


Allerdings gibt es hier dennoch einige Unsicherheitsfaktoren. Um ganz sicher zu gehen bietet es sich an, den aktiven Knoten eine zeitlang alleine weiterlaufen zu lassen und einen Termin anzusetzen, zu dem man auch den aktiven Server anhält (alle Prozesse die auf MySQL zugreifen), dort erneut ein Dump erstellt und die Replikation komplett von vorne startet. Denn nur dann ist auch garantiert das diese sauber anläuft. Die Ausfallzeit liegt normalerweise im Bereich von 5 bis 10min.



greetz
Poison Nuke

bearbeitet von Poison Nuke, am 15.06.2012, um: 04:48:55


DarkSubZero

#2 Verfasst am 18.09.2009, um 07:16:01



Überwältigender Beitrag Poison!

Schade nur, dass ich nichts davon verstehe obwohl es sehr interessant klingt.

Könntest du vielleicht mit ein paar einfachen Worten erklären was das jetzt fürs Forum heißt?

Und ich dachte schon ich wäre der einzige gewesen der letzte Nacht einen ausführlichen Beitrag geschrieben hat, aber meiner ist ja auch erst zu einem Viertel fertig.



 Poison Nuke  *

#3 Verfasst am 18.09.2009, um 10:04:56



fürs Forum heißt das:

wenn alles so läuft wie gedacht (:X), dann kann ein Server ruhig wegen Hardware-versagen oder wegen was auch immer ausfallen, das Forum läuft weiter. Es gab ja in Vergangenheit schon ein paarmal das Problem, das z.B. einfach mal das Netzteil vom Server versagt hatte oder durch ein automatisches Update der Software der Server und damit das Forum einfach offline war.

Mit dem Konzept sind aber immer zwei Server parallel für das Forum zuständig, sollte ein Server warum auch immer ausfallen, dann bleibt das Forum weiterhin online. Zumindest in der Theorie.
Das größte Problem wird halt sein zu erkennen, wann die Replikation durch einen Fehler stoppt. Bisher sind mir erst zwei Wege bekannt bei denen die Replikation aufhört...ersterer ist ein Bug von MySQL wo Datensätze falsch angelegt werden (was ich mit slave-skip-errors=1062 ausgeklammert habe) und dann kann es weiterhin sein das der Slave nach einem Absturz nicht auf die aktive Session des Master zugreifen kann.



Aus dem Grund lasse ich auch den Apache Webserver nicht automatisch starten, damit bei einem Absturz von einem Server ich erstmal die Replikation wieder zumlaufen bringen kann eh Daten geschrieben werden. Nat. blöd wenn beide Server abstürzen...aber das hoffen wir mal nicht das es nochmal passiert :L


greetz
Poison Nuke

DarkSubZero

#4 Verfasst am 18.09.2009, um 11:04:18



Was wäre denn, wenn wieder so ein Serverupdate kommen würde, das würde doch beide Server gleichzeitig "befallen" könnte es damit dann nicht auch wieder zu Problemen kommen?



 Poison Nuke  *

#5 Verfasst am 18.09.2009, um 11:27:22



nö, jetzt ist es ja kein Windows mehr und Debian macht sowas nicht :D

da kann ich dann ganz in Ruhe einen Server aus der Replikation herausnehmen, das Update fahren und prüfen ob alles funktioniert und dann die Replikation wieder starten...theoretisch...bisher liegt noch kein Update vor das gemacht werden müsste :X
zudem Debian im laufenden Betrieb theoretisch geupdatet werden kann ohne das irgendwas beendet werden muss, im Gegensatz zu Windows.


greetz
Poison Nuke

DarkSubZero

#6 Verfasst am 18.09.2009, um 11:53:26



Das hört sich in der Theorie schon mal super an. Hoffen wir mal dass es dann auch so klappt.



Cattivo

#7 Verfasst am 18.09.2009, um 17:22:33




Poison Nuke schrieb:
... zudem Debian im laufenden Betrieb theoretisch geupdatet werden kann ohne das irgendwas beendet werden muss, im Gegensatz zu Windows.

Ja, das dachte ich auch immer. Ist aber leider wirklich nur Theorie. Die Praxis schaut anders aus.

Totzdem eine gute Entscheidung von dir auf Debian, anstelle auf Windows, für einen Internetserver zu setzen.


Gruß Markus
Mein Heimkino

 Poison Nuke  *

#8 Verfasst am 18.09.2009, um 17:57:33



naja, wir haben hier einige Server mit Debian Sarge (also schon recht alt) die haben eine Uptime von über 3 Jahre ohne ein einziger Reboot. Also ganz so schlecht kann es dann wohl nicht sein 8)




aber geht jetzt zu OT hier. Sollte in dem Thread bitte bei der Master-Master Replikation bleiben.


greetz
Poison Nuke

 Poison Nuke  *

#9 Verfasst am 20.09.2009, um 18:46:14



Zwischeninfo:

es ist nicht möglich eine Master-Master Replikation weiter zu replizieren auf einen dritten Slave. Das hatte ich versucht und wunderte mich, warum der Datenbestand von dem Slave unterschiedlich zu dem der Masterserver ist...es fehlten immer ein paar Einträge, es wurden aber keine Fehler bei der Replikation angezeigt. Zuerst hatte ich da nicht weiter nachgeforscht. Als ich aber heute mal ein "ALTER TABLE" auf dem zweiten Master gemacht habe (der Slave repliziert von dem ersten Master), kam der nie beim Slave an. Ich dachte es gäbe einen Fehler und habe dann halt die Replikation neu gestartet...

das Neustarten der Replikation geht im übrigen sogar ohne Unterbrechung der Master-Master Replikation. Ich habe auf dem ersten Master den Apache angehalten, damit alle User auf den zweiten Server geleitet werden, dann hab ich wie oben beschrieben die Tabellen gelockt, ein Dump gemacht und mit Masterlogpos notiert und damit den Slave erneut gestartet (und danach dann nat. den ersten Master wieder zurück in den normalen Betrieb genommen).

Der Slave ist auch ohne Fehler angelaufen und hatte auch alle Updates erhalten...naja bis ich auf dem zweiten Master wieder ein paar Testeinträge macht und die einfach nicht ankamen.


Daher hab ich nachgeforscht und die Option


Quellcode
--log-slave-updates


gefunden. Diese Option muss man bei einem Slaveserver aktivieren damit er die Updates die er vom Master bekommt an weitere Slaves sendet. Daher kamen die Updates vom zweiten Master nie an, weil der erste Master ja auch Slave ist und daher diese Updates nicht im Binlog speicherte.
Ich müsste also auf dem ersten Master diese Option aktivieren.

Nur würde ich das machen...dann hätte unser Forum binnen Sekunden ein paar Millionen Beiträge usw...bis es abstürzt. Denn mit dieser Option beginnt ein Ping-Pong Effekt. Denn beide Master sind auch Slaves vom anderen. D.h. wenn der zweite Master ein Update hat, dann schickt er es an den ersten Master...dieser speichert es aber in der Binlog ab sodass er es wieder an den Slave schickt...der der zweite Master ist. Damit würde der zweite Master immer einen doppelten Datenbestand haben...und wenn man die Option auf diesem auch noch aktiviert dann beginnt eine Endlosschleife.


greetz
Poison Nuke

 Poison Nuke  *

#10 Verfasst am 22.11.2009, um 12:26:04



eben hatte einer der beiden Server einen Ausfall gehabt und war nicht mehr erreichbar...nach einem Neustart kam er aber wieder problemlos hoch und oh Freude, kein Fehler beim Wiederverbinden mit der Datenbank. der Apache hatte aber nicht gestartet damit ich erst prüfen kann ob MySQL wieder läuft aber es scheint kann man da fast sorgenfrei sein, diesemal ging es schön reibungslos und der zweite Server nahm den Betrieb wieder auf ohne das man am Forum was merkte :hail




greetz
Poison Nuke

 Poison Nuke  *

#11 Verfasst am 16.06.2010, um 17:33:49



aufgrund einer Änderung bei MySQL habe ich die Syntax für "GRANT" angepasst, dies funktioniert nun auch mit aktuellen Versionen von MySQL.


greetz
Poison Nuke

 Poison Nuke  *

#12 Verfasst am 10.09.2010, um 00:51:08



Sollte jemand eine Replikation benötigen, bei der mehr als eine Datenbank repliziert wird, oder sogar im laufenden Betrieb neue Datenbanken erstellt oder gelöscht werden, der muss die gesamte Replikation anders anfangen. Hier im Thread wurde die Replikation für eine einzige Datenbank eingerichtet. Im Nachhinein eine neue Datenbank hinzuzufügen ist nicht möglich.


Um das aber zu ermöglichen, muss folgender Part der Startkonfiguration angepasst werden:



Poison Nuke schrieb:

/etc/mysql/my.cnf

master:

Quellcode
[mysqld]

server-id               	= 1
replicate-same-server-id	= 0
auto-increment-increment	= 2
auto-increment-offset   	= 1

master-host     = backup.poisonnuke.de
master-user     = master
master-password = passwort
master-connect-retry    = 60
replicate-do-db = forum
binlog-do-db    = forum
slave-skip-errors = 1062


backup:

Quellcode
[mysqld]

server-id               	= 2
replicate-same-server-id	= 0
auto-increment-increment	= 2
auto-increment-offset   	= 2

master-host     = master.poisonnuke.de
master-user     = backup
master-password = passwort
master-connect-retry    = 60
replicate-do-db = forum
binlog-do-db    = forum
slave-skip-errors = 1062





der entscheidende Teil ist das
replicate-do-db = forum
binlog-do-db = forum



dies muss nun geändert werden in:
replicate-ignore-db = mysql
replicate-ignore-db = information_schema
binlog-ignore-db = mysql
binlog-ignore-db = information-schema


und wenn noch weitere Datenbanken vorhanden sind, die nicht repliziert werden dürfen, müssen diese entsprechend hinzugefügt werden.
Auf diese Weise werden sämtliche anderen Datenbanken repliziert. wird mit "CREATE DATABASE" oder "DROP DATABASE" nun eine Datenbank entfernt, dann wird dies ebenfalls auf dem Slave ausgeführt.










Noch ein weiteres Tool:
Prüfen ob zwei Tabellen identisch auf beiden Servern sind

um sicherzugehen, dass wirklich alles stimmt (denn es werden nur die Änderungen repliziert und nie geprüft ob alles stimmt), kann man mit folgendem Befehl testen, ob zwei Tabellen übereinstimmen


Quellcode
CHECKSUM TABLE tabelle


das muss auf beiden Servern ausgeführt werden und dann hat man CRC32 Checksummen von der gesamten Tabelle. Wenn beide Zahlen identisch sind, dann ist alles iO.

Wenn nicht, dann sollte man zur Sicherheit einfach die Replikation auf einem der Server neu aufsetzen. Den Fehler in einer umfangreichen Tabelle zu finden kann schon etwas aufwändig werden, bei Forum mit bald einer viertel-Million Beiträgen wäre das z.B. lustig :D


greetz
Poison Nuke

 Poison Nuke  *

#13 Verfasst am 12.09.2010, um 17:47:25



hier im Thread hab ich etwas ausführlicher die automatisierte Überwachung erklärt:

http://forum.poisonnuke.de/index.php?action=ViewThread&TID=5666




greetz
Poison Nuke

PN's Forum \ Computer \ Programmierung \ Webentwicklung \ MySQL - Aufsetzen und Betrieb einer Master-Master Replikation


- Zurück zur Homepage - Eigene Beiträge - Neue Beiträge - Wer ist online? - Impressum - Datenschutz - Statistiken -



Board coded and provided by: Poison Nuke
Copyright 2007-2014, Robert Menger