ich hab mir das mal aufgemalt, wie ich glaube, die planung der infrastruktur verstanden zu haben.
gruen sind die datenfluesse, gelb sind die namensaufloesungen und rot sind die kommunikationen zwischen den db-stubs, die sich ueber die synchronisation absprechen.
fuer mich seht das ehrlich gesagt ziemlich freaky aus.
und genau gesagt kann das so auch nicht funktionieren. zumindest fuer den fall, dass eine der beiden seiten ausfaellt und auf beiden seiten weiterhin schreibzugriff moeglich sein soll. denn dann ist naturgemaess eine resynchronisation angesagt. die birgt typische transaktionsprobleme mit sich und kann beweisbar nicht korrekt funktionieren (und das ist kein boeser wille von mir!). alle, die sich den beweis nicht anschauen wollen, koennen das lesen des beitrags hier beenden
wovon ich ausgehe ist, dass die funktionalitaet der forensoftware nicht ausschliesslich aus sql-anfragen besteht, d.h. also die berechnungen und auswertungen etc. mindestens teilweise im php ablaufen und auch die eingaben fuer die berechnungen von aussen kommen, was leicht einzusehen ist.
sei nun eine solche situation gegeben, in der die beiden db-stubs sich nicht mehr sehen. es werden nun auf beiden seiten unabhaengig voneinander berechnungen vorgenommen. z.b. wird auf seite 1 ein wert X aus der datenbank gelesen, eine berechnung in php damit durchgefuehrt und ein neuer wert Y ermittelt, der zurueckgespeichert wird. auf seite 2 passiert etwas aehnliches, nur dass der wert hier zu Y' ausgewertet wird. Y ist normalerweise ungleich Y', da die berechnung nicht ausschliesslich von X abhaengt, sondern ebenso von eingaben der benutzer. eine transaktion finden nun praktisch gesehen zeitlich nach der anderen statt. beim resynchronisieren, steht man nun vor dem problem, ob man Y oder Y' uebernimmt... denkt man vielleicht. das wahre problem ist aber, dass die eingabe fuer eine der beiden transaktionen schon niemals X haette sein duerfen, sondern entweder Y, wenn die erste transaktion vor der zweiten standgefunden hat, oder Y' im umgekehrten fall. d.h. also dass weder Y noch Y' korrekt ist, weil die letzte transaktion eine falsche eingabe bekommen hat und das korrekte ergebnis bei einer intakten kommunikation zwischen den db-stubs ein Z gewesen waere. dieses problem nennt man auch "dirty read"
beispiel:
in einem thread werden bilder gepostet. nun faellt die kommunikation zwischen den dbs aus. jemand meint, das bild, welches im letzten beitrag von ihm bepostet worden ist, sei doch nicht so gut geeignet und entfernt es, z.b. auf seite 1. auf seite 2 jedoch gibt es einen anderen user, der auf dieses bild eingeht und dazu einen beitrag verfasst. nun wird die verbindung zwischen den dbs wiederhergestellt. was ist zu tun? nun hat man den zustand, dass a) ein beitrag geloescht wurde und b) es einen neuen beitrag gibt, der sich auf den geloeschten beitrag bezieht. das dbms kann keine kausalen zusammenhaenge erkennen, wodurch es nicht imstande ist, ueberhaupt nur zu erkennen, dass die beiden transaktionen sich gegenseitig beeinflusst haetten, waere die kommunikation nicht ausgefallen. so waere z.b. die antwort b) moeglicherweise niemals entstanden, wenn der beitrag a) mit dem bild vor dem erstellen der antwort geloescht worden waere. oder um umgekehrten fall waere der beitrag a) mit dem bild moeglicherweise nicht geloescht wurden, haette der verfasser gesehen, dass es schon eine antwort b) darauf gibt. diesen kausalen zusammenhang kann das dbms nicht erkennen, geschweige denn gar korrigieren. an dieser stelle wuerden auch wie bereits gezeigt zeitmarken nichts helfen, da sie ebensowenig den zusammenhang zwischen den beiden transaktionen widerspiegeln.
eine loesungmoeglichkeit waere es, eine der beiden dbs auf readonly zu setzen waehrend die kommunikation unterbrochen ist, aber dann steht man wieder vor der entscheidung, welcher db man den vorzug gibt...