Moin,
mit der Erfahrung einer von uns implementierten Async Multimaster Replikation mit ca. 160 Server in Deutschland
in diversen Städten verteilt, auf denen innerhalb von 24 Stunden ca 1,5 bis 2 Millionen neue oder geänderte
Datensätze entstehen, geb ich einfach auch mal meinen Senf dazu (auch wenn das alles mit Firebird und
nicht mit
mysql implementiert wurde).
-Wir benutzen 64 Bit Integer als PK und für jeden FK und in jeder Tabelle heisst das PK Feld immer ID
(vereinfacht nachher sehr viel)
-Integer ist schon eng, bei 24/7 Betrieb mit einer Transaktion pro Sekunde und wie wir alle wissen 86400
and den meisten Tagen hält ein 32 bit Integer zwar ca 130 Jahre bis zum Überlauf, aber bei 10 pro Sekunde
sind das nur noch 13 Jahre. 100 pro Sekunde dann nicht mal 1,5 Jahre. Beim 64 Bit kannst du 4 Mrd Werte pro
Sekunde verbraten und das hält immer noch 130 Jahre. Geiz ist nicht wirklich geil ....
-Alle Tabellen werden aus einer Quelle (also nur ein Firebird Generator) gefüllt
-An jedem Standort wird bei Auslieferung eine Boxnummer festgelegt und die mit 10 Mrd multipliziert ist der
Startwert für den Generator. Das reicht für ca 1,5 Mrd Standorte ....
-Bitte niemals auch nur drüber nachdenken, das für irgendwas Eindeutiges Timestamps geeignet sind (Sommerzeit und
Winterzeit Umstellung ist die einfachste Problematik dabei, die kann man über utc lösen, aber auflösung in ms ist
schon unter last sehr eng), unter Last sind 1000 Datensätze pro Sekunde nicht viel und der normale Timer insbesondere
unetr windows hat eine wesentlich miesere Auflösung als 1ms.
-Replikationskonflikte kann man asynchron nur dokumentieren, ähnlich wie Notes das macht. Auflösen kann man die
mit Regeln (wer zuletzt speichert hat gewonnen oder ähnlich)
-Inserts sind einfach zu replizieren, updates eher nicht: Einfaches Beispiel Artikellagerbestand, 2 Standorte
verringern den um 1 und weil internet down ist weiss keiner vom anderen. Besser Insert in Bestandsveränderungstabellen
lassen sich zeitnah zu einem Gesamtbestand konsolidieren, Startwert 10 vom zeitpunkt x, zugang +1 and zeitpunkt y
standort a, zugang +5 and zeitpunkt z standort b usw, wenn alle Standorte repliziert sind kann man dann 10+1+6=16
zusammenrechnen auf dem führenden System und den Wert in die Tabelle schreiben und die Bestandveränderungen löschen .
Dafür sollte die Datenbank 100% sauber Transaktionsfähig sein, sonst hast du eh nur datenmüll
-Bei 2 Standorten ist die Problematik noch relativ simpel, wenn man erkennen will, das einer Offline ist, bei 160
Standorten ist es fast immer so, das irgendwo ein Router hängt, dsl tot ist, ein Bagger kabel aus dem Boden gerissen
hat usw. Wichtig ist für unseren Kunden dabei, das an jedem Standort auch offline gearbeitet werden kann und sobald
das wieder online geht, möglichst schnell repliziert wird.
-Wir implementieren das mit Triggern, die immer dann wenn der replikationsuser was macht, inaktiv sind (das gilt für
alle Trigger). Massenoperationen (delete from tab oder ähnliches) können direkt in eine Replikationslog
Tabelle eingetragen werden, dann macht das der Replikationsuser an jedem Standort per skript ohne das es
über die Leitung gehen muss
-Wir bevorzugen lieber mehrere kleinere Tabellen als Monster mit hundetren Feldern
-über die in Firebird existierende Technik execute statement on external können wir auch Blob Inhalte replizieren,
die Technik eignet sich auch für synchrone transaktionechte Replikation
-Lösungen wie ibreplicator versprechen mehr als sie halten, ob die in
mysql eingebaute replikation was taugt
weiss ich nicht, aber die war mal bekannt dafür das die nur funktioniert wenn die
db komplett in den
Arbeitsspeicher passt .... Bei uns hat die zentrale
DB 290 GB und wächst täglich weiter, wäre also
technisch anspruchsvoll, das im
RAM zu haben ...
-Für den Delphi Programmierer,der die Backoffice Anwendung dafür schreibt, ist das alles transparent, er muss
sich nicht drum kümmern, was wann von wo nach wo geht. Das überwachen wir für den Endkunden automatisiert
und wir verteilen auch Metadatenupdates über ibexpert Techniken, weil wir per reverse
ssh tunnel auf
jeden Standort direkt mit ibexpert kommen. Firebird läuft an fast allen Standorten unter linux, mit
MSSQL basierender Replikation hätte der Kunde schon ohne Hardware 2-3 mio an Microsoft überweisen dürfen,
die von uns gelieferte hardware/software kombination kostet keine 1000 € pro Standort.
-Die Beschriebung geht wahrscheinlich weit über das hinaus, was du im Moment umsetzen willst, aber
sicherlich helfen da einige Aspekte, vermeidbare Fehler eben auch nicht zu machen. Ansonsten viel
Spaß bei der Umsetzung ....
Gruß
Holger