Stammtisch am 02. Oktober

Stammtische, Veranstaltungen lokal bis international, Freies Wissen, Netzpolitik, andere freie Netze und Gemeinschaften, Global.Freifunk.net
Antworten
Benutzeravatar
tmk
Beiträge: 1196
Registriert: 18.04.2007 12:18
Wohnort: Halle
Kontaktdaten:

Stammtisch am 02. Oktober

Beitrag von tmk »

Datum: Jeweils am ersten Donnerstag und dritten Dienstag im Monat
Zeit: Eintrudeln ab 19 bis 20 Uhr, je nach Lust, Laune, Themen und Aktionen gerne bis spät in die Nacht
Ort: Keller des Dinner for One, Große Brunnenstraße 2, Halle, Ex-Flimmrich

Ideen, Fragen, Anregungen hier. Bis dann!
SyntaxError: invalid syntax
Benutzeravatar
tox
Beiträge: 1417
Registriert: 11.08.2007 16:33
Wohnort: Halle
Kontaktdaten:

Re: Stammtisch am 02. Oktober

Beitrag von tox »

ich hab mir das mal aufgemalt, wie ich glaube, die planung der infrastruktur verstanden zu haben.
Bild
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 :mrgreen:

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...
みんなはばかだ。
Mein öffentlicher Schlüssel (OpenPGP)
Mein öffentlicher Schlüssel (SSH2, kommerzielles Format)
Verwalter von 7.42, 7.43, 7.44, 9.42, 10.42, 10.43, 15.42 und 28.1.
Anschluss: T-Com Call & Surf Comfort Plus inkl. HotSpot-Flat 16/1 Mbit
Modem, Router, TK-Anlage: Speedport W 700V
FF-Router: Buffalo WHR-HP-G54, FFF-Leipzig 1.6.10-core-1-halle-3, Doppel-Biquad-Antenne
Benutzeravatar
se
Beiträge: 939
Registriert: 17.08.2005 22:45

Re: Stammtisch am 02. Oktober

Beitrag von se »

ich würde sagen, das system php-interface<->mysql-datenbank ist nicht gut geeignet, um damit eine dezentrale und ausfallsichere kommunikationsinfrastruktur zu schaffen. auch wenn wir ein php-interface auf verschiedenen servern installieren und mehrere mysql-datenbanken clustern.

dafür war der ansatz mit den newsservern echt besser geeignet, aber da hat ja eine gute benutzerschnittstelle (sprich gutes webinterface) gefehlt. einen newsserver möchte ich auch nicht nochmal aufsetzen.

ich hab mich erstmal gefragt, ob man nicht zwischen das/die interface(s) und die datenbank(en) ein nachrichtenverteilungssystem, basierend auf moderner technologie (vielleicht xmpp aka jabber), setzen könnte, um das interface besser von der datenbank zu entkoppeln. bin mir nicht sicher, ob das die richtige richtung ist..
PapaBaer
Beiträge: 256
Registriert: 14.04.2008 00:19

Re: Stammtisch am 02. Oktober

Beitrag von PapaBaer »

tox hat geschrieben:ich hab mir das mal aufgemalt, wie ich glaube, die planung der infrastruktur verstanden zu haben.
Man Tox, das hatten wir doch nun oft genug. Dann lass es doch die Menschen aufmalen, die es verstanden haben oder die zumindest ein paar Vorstellungen über mögliche Lösungen im Kopf haben. Was sollen wir denn mit dem Durcheinander anfangen? Die Frage ob wir Datenbankproxies, -cluster oder -replikation benutzen ist doch noch gar nicht entschieden und braucht auch noch den ein oder anderen Versuch, so wie ein paar andere Sachen auch noch.

Wie oft brauchst du den Hinweis noch? Is doch noch gar nicht so lange her!

Stefan
Benutzeravatar
tox
Beiträge: 1417
Registriert: 11.08.2007 16:33
Wohnort: Halle
Kontaktdaten:

Re: Stammtisch am 02. Oktober

Beitrag von tox »

a) es ist ein entwurf, an der man rumopern soll, als art gedächtnisstützte, damit man mal ein paar gedanken zum thema fassen kann. sorry, wenn das nicht deutlich genug dran stand, aber das kann man sich eigentlich denken, wenn man die zeit lieber dafür verwendet, darübernachzudenken, anstatt wieder völlig gedankenlos auf den tox loszugehen. ;- )
b) ich denke schon, dass ich es weitgehend verstanden hab. zumindest haben wir uns über diese struktur unterhalten. zugegebenermaßen fehlt da die sache mit den redundanten dns-servern. wobei ich ja genau die weggelassen habe, weil genau das die sache ist, die ich nicht so verstanden hab. du kannst es mir aber gerne noch mal versuchen zu erklären und es sollte kein problem sein, das dann noch zu vervollständigen :- ) und es ist doch kein muss für die leute, wenn sie material posten, besonders, wenn es gerade mal um entwürfe geht, dass sie es komplett überschauen. entwürfe sind keine sicherheitsrisiken, wenn da jeder draufschaun kann, um sie zu revidieren. immerhin hab ich doch mal damit wenigstens angefangen, etwas mehr oder weniger informationshaltiges zu posten.
c) mit "db-proxy" meine ich im übrigen keinen datenbankproxy im engeren sinne, sondern eine beliebige möglichkeit, die datenbank durch eine zwischenschicht so zu abstrahieren, dass einerseits die daten tatsächlich in der eigenen datenbank landen und andererseits gleichzeitig mit dem anderen system abgeglichen werden.
d) ich hab dich doch auch lieb. :P

zum thema, damit das auch mal wieder produktiv hier wird im post:
ich bin ses meinung, dass eine (zumindest herkömmliche) schnittstelle zwischen db und php zu unsicher ist.
das problem mit dem clustering wird sein, dass es keine lösung geben wird, bei der beide teile des clusters gleichberechtigt sind. es gibt aber, wie ich gestern in erfahrung gebracht habe, einige brauchbare master-slave-lösungen.
みんなはばかだ。
Mein öffentlicher Schlüssel (OpenPGP)
Mein öffentlicher Schlüssel (SSH2, kommerzielles Format)
Verwalter von 7.42, 7.43, 7.44, 9.42, 10.42, 10.43, 15.42 und 28.1.
Anschluss: T-Com Call & Surf Comfort Plus inkl. HotSpot-Flat 16/1 Mbit
Modem, Router, TK-Anlage: Speedport W 700V
FF-Router: Buffalo WHR-HP-G54, FFF-Leipzig 1.6.10-core-1-halle-3, Doppel-Biquad-Antenne
PapaBaer
Beiträge: 256
Registriert: 14.04.2008 00:19

Re: Stammtisch am 02. Oktober

Beitrag von PapaBaer »

tox hat geschrieben:dass es keine lösung geben wird, bei der beide teile des clusters gleichberechtigt sind.
Gibt es:
http://dev.mysql.com/doc/refman/5.1/de/ ... r-faq.html

Genau so, wie es auch Master-Slave gibt:
http://dev.mysql.com/doc/refman/5.1/de/ ... intro.html

Aber alles hat seine Vor- und Nachteile und es muss ausgetestet werden. Und genau das ist mein Problem mit diesen Schnellschüssen, es sind eben nur Halbwahrheiten und setzt Verwirrungen in die Welt, die dann schwer wieder zu korrigieren sind.

Stefan
Benutzeravatar
tox
Beiträge: 1417
Registriert: 11.08.2007 16:33
Wohnort: Halle
Kontaktdaten:

Re: Stammtisch am 02. Oktober

Beitrag von tox »

es klingt schon irgendwie ironisch, wenn die dokumentation von mysql-clustern sich bei der kernfunktionalität auf transaktionen stützt, nicht wahr :mrgreen:

als wichtige einschränkung erwähnt die doku, dass solche cluster für verbindungen mit 100 mbit ausgelegt sind, nicht für internet.

bisher nahm ich an, dass wir es imgrunde so machen wollen, dass wir ein system im internet haben und ein system im freifunk (wegen des redundanzgedankens). dabei gibt es 2 ausfallmomente. zum einen kann ein rechner oder eine verbindung innerhalb eines der beiden netze ausfallen, entweder im freifunk oder im internet. oder es kann die verbindung zwischen freifunk und internet ausfallen. mysql-cluster sind darauf vorbereitet, dass einzelne rechner ausfallen oder auch einzelne verbindungen zwischen den rechnern. worauf sie nicht vorbereitet sind, ist, dass der cluster komplett in 2 teile geteilt wird, was quasi dem zweiten fall entsprechen würde, wenn die verbindung zwischen freifunk und internet abbricht. insofern ist die funktionsweise auch mit einem raid vergleichbar. jedenfalls wollen wir aber genau dieses problem lösen, dass die daten synchron bleiben, obgleich diese verbindung unterbrochen ist. daher bin ich der meinung, dass diese mysql-cluster uns nicht bei dem problem weiterhelfen.

testen kannst du doch gerne machen, aber das ersetzt nicht die kommunikation und diskussion über praktikable lösungen, die ich hiermit eigentlich beabsichtige.

nichtsdestotrotz möchte ich noch einmal erwähnen, dass wir ebenso postgres in betracht ziehen können. die das problem natürlich auch nicht besser lösen, weil es nicht (zumindest nicht perfekt) geht, wie ich in meinem ersten beitrag geschildert habe. ich hab mal ein dokument rausgesucht, dass die wesentlichen möglichkeiten bündig zusammenfasst: http://samson.fire.uni-bremen.de/waldma ... ial_06.pdf

ein anderer gedanke beschäftigt mich auch noch. ist es überhaupt sinnvoll, um jeden preis eine redundante datenbank aufzubauen und hilft uns das bei einer angemessenen anzahl an problemen weiter. ich glaube, bei einem solchen angriff, durch den die diskussion ursprünglich ins rollen gekommen ist, würden redundante datenbanken auch schön redundant in mitleidenschaft gezogen werden. wäre es nicht eher sinnvoller, allgemein mehr auf sicherheit zu achten (z.b. komplexere passwörter), damit sowas nicht wieder passiert, anstatt alles mit redundanz erschlagen zu wollen? jedenfalls hatte ich nicht den eindruck, dass die forensoftware selbst oder die dahinterliegende datenbank irgendwie unzuverlässig wären.
みんなはばかだ。
Mein öffentlicher Schlüssel (OpenPGP)
Mein öffentlicher Schlüssel (SSH2, kommerzielles Format)
Verwalter von 7.42, 7.43, 7.44, 9.42, 10.42, 10.43, 15.42 und 28.1.
Anschluss: T-Com Call & Surf Comfort Plus inkl. HotSpot-Flat 16/1 Mbit
Modem, Router, TK-Anlage: Speedport W 700V
FF-Router: Buffalo WHR-HP-G54, FFF-Leipzig 1.6.10-core-1-halle-3, Doppel-Biquad-Antenne
Antworten