[TYPO3-german] Verteiltes Typo3 System

[Markus Deckmann]

Hi Patrick,

> Grundsätzlich wäre es sicherlich der einfachste Ansatz, wenn die 
> Redaktionssysteme auf der zentralen Datenbank arbeiten könnten. Da dies 
> durch deinen Ansatz (z.B. digitale Mauer) nicht gewollt ist, kommen 
> meiner Meinung zwei Ansätze in Frage - beide mit einigem Aufwand verbunden:

Hier könnten auch firmenpolitische Dinge mit reinspielen welche eine 
zentrale Datenbank verhindern. ;-)


> Erstens, eine verteilte Datenhaltung mit einer Master-Slave 
> Konfiguration und Replikation des DBMS - sprich lokale Datenbanken vor 
> Ort in den einzelnen Ländern / Kontinenten. Hierbei hast du dann 
> allerdings gleich mehrere Probleme. Die Replikation sollte fein 
> eingestellt werden, dass nur die benötigten Daten von den lokalen DBs in 
> den Master zurück gespielt werden. Caching Tabellen und Co, sollten von 
> der Synchronistation / Replikation ausgenommen werden. Das wird in dem 
> Artikel auch kurz angerissen. Mehr Infos zu MySQL [1]

Ok, aber hiermit wird stets die gesamte Webseite inkl. aller Sprachen 
(sprich aller Seitenbäume in allen Sprachen) synchronisiert so wie ich 
das verstehe? Sprich Land 1 besitzt in seiner DB ebenfalls die Daten von 
Land 2, Land 3, Land x, obwohl Land 1 gar keinen Zugriff auf diese Daten 
hat, oder? Je nach Anzahl der Länder führt dies zu einem höheren Traffic 
bei der Synchronisation den ich verhindern wollte.


> Zweitens, eine verteilte Datenhaltung mit einer selbstgefertigten 
> Synchronisation via TYPO3 Hack, Skripte und Co. Dafür könnte sich das 
> oben erwähnte Staging System eignen.

Hier müsste ich dann wie ich dich verstehe vor allem den Seiten-ID 
Mechanismus von Typo3 anfassen und dafür sorgen das keine doppelten IDs 
in den einzelnen Redaktionssystemen vorkommen können, oder?


> Grundsätzlich würde ich die verteilte Datenhaltung allerdings nur als 
> Fallback Lösung verwenden und die lokalen Backend Instanzen auf dem 
> Master DB Server arbeiten lassen. Sollte der einmal nicht zur Verfügung 
> stehen, dann kann auf die lokale Replikation ausgewichen werden und 
> diese nachdem der Master wieder zur Verfügung steht zurückgespielt und 
> die DB des Backends wieder umgestellt werden.

Wie gesagt, die zentrale DB-Lösung ist so eigentlich nicht gewünscht. 
Aber wenn es nicht anders geht muss es natürlich so laufen. Bei deiner 
vorgeschlagenen Fall-Back-Lösung habe ich allerdings immer noch das 
Problem das im Fall des Fallbacks der Master-DB-Server ja nicht von 
allen Instanzen nicht erreichbar sein könnte und somit x Systeme auf dem 
Master-System arbeiten, wohingegen n Systeme auf Ihrer lokalen 
Replikation arbeiten. Beim zurückspielen der lokalen Replikation (zum 
Zeitpunkt des Wieder-Erreichens des Master-DB-Servers) können IMHO 
wieder Fehler anhand von doppelten IDs o.ä. auftreten.

Ciao Markus