Multimaster MySQL

Multimaster MySQL Arne Blankerts, IPC Spring 2009, Berlin 27. Mai 2009

Wer sind wir Premium PHP Consulting & Training. Worldwide. Arne Blankerts Sebastian Bergmann Stefan Priebsch

Disclaimer

Master & Slave Zwei oder mehr MySQL Server in Abhängigkeit

Master & Slave

Lesezugriffe erfolgen am Slave
Schreibzugriffe auf den Master

Änderungen beim Slave führen zu Problemen

Replikation bricht ab
Inkonsistenzen drohen

Ideal für load-balancing bei

SELECT-lastingen Seiten
Aufwendigen Suchen
Wenigen Schreibzugriffen

Kann als Fallback zum Master werden

Master & Slave [theseer@nodeA etc]$ cat my.cnf # node A - setup [mysqld] server-id = 10 [theseer@nodeB etc]$ cat my.cnf # node B - setup [mysqld] server-id = 20 master-host = nodeA.example.org master-user = nodeAuser master-password = nodeApass

Doppelpack Zwei Master Server?

2 Master Server

Setup

2 MySQL Server Instanzen

MySQL Version 4.1 oder höher

Replikation via MySQL

Gleiche Serverversionen notwendig

Zwei Master Server [theseer@nodeA etc]$ cat my.cnf # node A - setup [mysqld] server-id = 10 master-host = nodeB.example.org master-user = nodeBuser master-password = nodeBpass [theseer@nodeB etc]$ cat my.cnf # node B - setup [mysqld] server-id = 20 master-host = nodeA.example.org master-user = nodeAuser master-password = nodeApass

$Master++ Weitere MySQL Server als Master

$Master++

Architekturfrage

Ringverbindung
Stern
Mixed

Probleme Oder: Was schief gehen kann wird schief gehen.

Auto_increment

Zeitgleiches einfügen

führt zu Doppelten Ids
lässt die Replikation abbrechen
sorgt für inkonsitente Abhängigkeiten

Auto_increment

MySQL Variablen

auto_increment_increment

Faktor, um den bei jedem Increment erhöht wird

auto_increment_offset

Wert, bei dem originär begonnen wird

Auto_increment (2) [theseer@nodeA etc]$ cat my.cnf # node A - setup [mysqld] Server-id = 10 master-host = nodeB.example.org master-user = nodeBuser master-password = nodeBpass auto_increment_increment = 10 auto_increment_offset = 1 [theseer@nodeB etc]$ cat my.cnf # node B - setup [mysqld] Server-id = 20 master-host = nodeA.example.org master-user = nodeAuser master-password = nodeApass auto_increment_increment = 10 auto_increment_offset = 2

Updates und Delete

Updates können sich gegenseitig überschreiben

Keine Garantie, welches Update ”gewinnt”

Delete und Update können sich in die Quere kommen

Was passiert wenn eine Node versucht einen Datensatz zu ändern, der auf der anderen Node schon gelöscht wurde?

Updates und Delete

Keine automatisierte Lösung möglich
Architekturfragen:

Müssen Daten gelöscht werden?
Sind zeitkritische Updates notwendig?

Könnte man das durch Versionierung umgehen?

Erlaubt leicht syncronisierbare Inserts

Cluster verwenden
Master-Slave verwenden

Temporäre Tabellen

Werden syncronisiert

Führt zu Problemen beim Re-Sync einer Node

Temporäre Tabellen

Fester Tabellenname?

Replication-ignore-table Option verwenden

Mysql 5.1+

Auslagern in extra Datenbank

Diese Datenabnk nicht replizieren

Option Replication-ignore-db

Eventuell FEDERATED Tables verwenden

Erlaubt Zugriff auf Remote Server
Setzt MySQL 5.0.3+ voraus

Zeitverschiebung

MySQL Replikation erfolgt asyncron

Zeitlich versetzte Aktualisierung

Unterschiedlicher Datenstand möglich

Zeitverschiebung

Up2date-Hack verwenden

Federated Table mit Timestamp
Bei Überschreitung einer TTL auf Master direkt zurückgreifen

Cluster für syncrone Replikation

Cluster [theseer@cluster etc]$ cat my.cnf [mysqld] ndbcluster ndb-connectstring=management.example.org [ndbd] connect-string=management.example.org [ndb_mgm] connect-string=management.example.org [ndb_mgmd] config-file=/etc/ndb_config.ini

Cluster [theseer@cluster etc]$ cat ndb_config.ini [ndbd default] NoOfReplicas= 2 DataDir= /var/lib/mysql-cluster [ndb_mgmd] Hostname= management.example.org DataDir= /var/lib/mysql-cluster [ndbd] HostName= ndbd1.example.org [ndbd] HostName= ndbd2.example.org [mysqld] [mysqld]

NonFood Textdatenbank Ein Praxisbericht

Textdatenbank