[TYPO3-german] Verteiltes Typo3 System

[Patrick Rodacker]

Hallo Markus,

Markus Deckmann wrote on 18.06.2008 12:36:

>> 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?

Ich denke du brauchst den Mechanismus von TYPO3 selber nicht direkt 
anfassen, du musst nur sicherstellen, dass ein ausreichend großer 
Bereich an ids für die entsprechenden Instanzen vorgehalten wird. Du 
kannst MySQL mitteilen wo der Index für die IDs beginnt und so z.B. 
China Ids mit 200000 starten und Europas mit 800000. Das dann für alle 
Tabellen die synchronisiert werden müssen.

>> 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.

ja, wobei ich ehrlich gesagt auch nicht weiß, wie das der 
Replikationsmechanismus von MySQL intern umsetzt und was in dem Fall 
eines längeren Ausfalls von Slave und Master passiert. Das was ich dazu 
in der Doku kurz gesehen habe machte eher den Anschein, dass der Slave 
dann die verlorene Zeit (Zeitraum der Unterbrechung) erst wieder 
aufholen muss. Wie es mit den in der Zwischenzeit durchgeführten 
Änderungen auf dem lokalen System aussieht weiß ich nicht.

Warum müssen die Instanzen der Kontinente denn eigentlich in einem 
Master synchronisiert werden, wenn du lokal eine Unabhängigkeit 
gewährleisten willst?

Ich bin jetzt erstmal ein paar Tage offline, wünsche dir aber viel 
Erfolg bei der weiteren Konzeption und Planung.

Besten Gruß
Patrick

[1]