nicht angemeldet
Moin Auge,
sorry fürs Denglisch, ich bin heute völlig im Arsch und es fällt mir schwer, die deutschen Begriffe zu finden.
… oder, falls man darauf Zugriff hat, die Nutzung von Replikation oder besser Clustern auf mehreren physikalischen Maschinen. Das ist dann aber der letzte Schritt nach dem Ausschöpfen aller Optimierungsmöglichkeiten.
Wobei das wiederum einen ganzen Rattenschwanz anderer Probleme nach sich zieht, besonders bei Multi-Master-Replikation.
Die Fallstricke kann ich, ehrlich gesagt, nicht beurteilen. In meiner Firma wird leise und nicht gerade intensiv über die Replikation eines MS-SQL-Servers nachgedacht. Bisher kenne ich das Konzept auch nur daher und auch nur theoretisch.
Nun, die allgemeinen Fallstricke bei Replikation sind halt so Sachen wie replication lag (asynchron), lange response times (synchron), disappearing nodes, halt die üblichen Probleme, die bei Netzwerk-Kommunikation auftreten können. Bei Multi-Master kommen dann noch andere fiese Probleme dazu: conflicts (z.B. INSERTs auf dem gleichen pk, oder UPDATEs auf der gleichen row, DELETE vs UPDATE, etc, pp), diverging nodes, DDL conflicts, semantic conflicts, Probleme durch Trigger, etc, pp.
Und das sind alles Probleme, die das DBMS nicht für einen lösen kann, das muss der application developer tun.
Da es das bei MySQL auch gibt, wollte ich auf die Existenz dieser Features hingewiesen haben. Für das hiesige Publikum wird der bewusste Zugriff darauf sowieso eher selten möglich sein.
Das ist vermutlich richtig, ja.
LG,
CK
Der Martin
Auge