MySQL-Replikation für Fallback-Szenario

Question

Wenn ich zwei MySQL-Server habe, die unterschiedliche Aufgaben haben (unterschiedliche Datenbanken enthalten), aber einen von ihnen verwenden möchten, um einzuspringen, wenn der andere ausfällt, was würden Sie mir dann vorschlagen, wie ich die Daten auf beiden gleich „nahe“ halte? in Echtzeit"?

Offensichtlich ist es nicht möglich, alle x Minuten einen vollständigen Datenbank-Dump zu erstellen.

Ich habe darüber gelesen Binärprotokoll, ist das der Weg, den ich gehen muss?Wird der Fallback-Server dadurch nicht stark verlangsamt?Gibt es eine Möglichkeit, einige Tabellen nicht in das Binärprotokoll aufzunehmen, bei denen es keine Rolle spielt, dass sich die Daten geändert haben?

Answer 1

Binäres Log ist definitiv der richtige Weg.Allerdings sollte man sich darüber im Klaren sein MySQL Sie können nicht einfach so zwischen den Servern hin und her wechseln.

Ein Server wird der sein Meister und der andere wird der Sklave sein.Sie schreiben/lesen auf den Master, können aber nur vom Slave-Server lesen.Wenn Sie jemals auf den Slave schreiben, sind diese nicht mehr synchron und es gibt keine einfache Möglichkeit, sie wieder zu synchronisieren (im Grunde müssen Sie sie austauschen, damit der Master der neue Slave ist, aber das ist ein mühsamer manueller Prozess ).

Wenn Sie echte Hot-Swap-fähige Backup-Datenbanken benötigen, müssen Sie möglicherweise auf ein anderes System umsteigen MySQL.Wenn Sie lediglich ein schreibgeschütztes Live-Backup wünschen, das Sie im schlimmsten Fall (Master wird dauerhaft zerstört) sofort verwenden können, ist Binary Log genau das Richtige für Sie.

Answer 2

Vielleicht möchten Sie darüber nachdenken Meister-Meister Replikationsszenario, jedoch mit einer kleinen Wendung.Sie können angeben, welche Datenbanken repliziert werden sollen, und die Replikation für jeden Server einschränken.

Für server1 würde ich hinzufügen --replicate-do-db=server_2_db und auf Server2 --replicate-do-db=server_1_db zu Ihrer my.cnf (oder my.ini unter Windows).Dies würde bedeuten, dass nur Anweisungen für server_1_db auf server2 repliziert würden und umgekehrt.

Bitte stellen Sie außerdem sicher, dass Sie regelmäßig vollständige Sicherungen durchführen und sich nicht nur auf die Replikation verlassen, da diese keinen Schutz vor versehentlichem Versehen bietet DROP DATABASE Aussagen oder ähnliches.