Hallo Markus, >> Du kannst ein Staging System zwischenschalten, das ist der neue >> Master. Die einzelnen Redaktionssysteme (Slaves) haben dann z.b. eine >> stündliche Spiegelung mit dem (Staging) Master. Dieser wiederum wird >> einmal täglich mit dem Live System abgeglichen. Der Abgleich muss dann >> natürlich auf Datei- und DB-Basis stattfinden. > > Damit schaltest du aber doch nur eine weitere, nicht notwendige Ebene, > dazwischen. Der Staging-Master in deinem Beispiel wäre eines der > Live-Systeme in meinem Beispiel. Dieses eine Live-System stellt das > Master-Live-System dar welches an m Stellen gespiegelt wird. ;-)
ja richtig, das war in Hinblick auf die verschiedenen Backends eine Überlegung, um Zeit für die Zusammenführung zu haben, wenn du mehrere eigenständige Systeme verwendest. > Wie gesagt, hier sehe ich noch keine Probleme mit der Spiegelung sobald > dieses Master-Live-System einmal vorhanden ist, allerdings mit dem > Vorgehen wie ich dieses Master-Live-System aus mehreren > Redaktionssystemen überhaupt zusammenstellen soll. > > >> Mich würde allerdings doch mal interessieren, warum du mehrere >> Redaktionssysteme einsetzen willst? Rein von der Performance her >> solltest du mit Loadbalancing und DB-Cluster auch im Backend exzellent >> skalieren können. > > Mehrere Redaktionssysteme weil die Redaktionen mehrsprachig sind und > jeweils nur auf die Inhalte ihrer Landessprache Zugriff haben sollen, > zudem auf versch. Kontinenten stehen wodurch die Zugriffszeiten > beinflusst werden könnten. Wenn man bspw. China mal als Beispiel nimmt > und davon ausgeht das diese Ihre digitale Mauer einmal schließen wäre > für ganz China die Webseite in diesem Zeitraum nicht mehr erreichbar. > Daher sollen auf den verschiedenen Kontinenten eigene Server stehen > welche die Seite hosten. > > Eine einfaches DB-Cluster würde hier allerdings wieder Traffic erzeugen > der nicht notwendig ist (außer es geht nicht anders), weil es für die > einzelnen Kontinente nicht notwendig ist die Daten der anderen > Kontinente zu spiegeln, sondern lediglich Ihre eigenen. Daher meine Idee > einfach mehrere Typo3-Instanzen zu nutzen mit jeweils einem Seitenbaum > in der jeweiligen Sprache und der nachherigen Zusammenführung in ein > Master-System das alle Seitenbäume in allen Sprachen enthält. 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: 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] 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. 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. Grüße Patrick [1] http://dev.mysql.com/doc/refman/5.1/en/replication.html _______________________________________________ TYPO3-german mailing list TYPO3-german@lists.netfielders.de http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-german
