Wie löst ihr das "Problem" eines jeden BG's. Ihr startet mit einem Server, der alles löst macht und leiden muss. Irgendwann ist das Game mal beliebter, und ihr wollt das ganze auf Server verteilen. So weit so gut. Mit Apache haben wir da wohl keine großen Probleme.
Was aber, wenn es an die MySQL geht. In dem Game, an dem ich bis vor kurzem mitgeschraubt habe, hatten wir testweise MySQL mit Replikation am laufen, waren aber nicht gerade sehr begeistert.
Wie sehen eure Erfahrungen aus ? Alternativen ?
Danke
Replikation mit MySQL und Co
gepostet vor 18 Jahre, 6 Monate von crawling
gepostet vor 18 Jahre, 6 Monate von The_Alien
Ich könnte mich ja irren aber dafür bietet Mysql doch eine extra Clientfunktion oder? (habe nur mal davon gelesen aber noch nicht selber genutzt)
gepostet vor 18 Jahre, 6 Monate von Sarge
Ein sehr interresantes Problem und ich würde mich auch sehr über Erfahrungswerte freuen da dies auch zu eines unseren größten Problemen gehört.
Zum einen gibt es ja Replikations Master/Slave Methode und Clustertabelen. Davon haben wir erstmal die Hände weggelassen da wir denken dass einfach der Kommunikationsaufwand dem Nutzen bei einem BG übersteigt. Gerade mal nachgeschaut es stehen bei uns z.b. 475Mio selects zu 151 Mio schreibenden Operationen also grob 3:1 .. ungünstig :/
Wer hier erfahrungen posten könnte dass es sich trotzdem lohnt /lohnen kann bitte posten
Ansonsten gibt es noch die alternative die Datenbank semantisch in mehrere zu splitten und diese auf getrennten Server laufen zu lassen .. war uns aber zu fehleranfällig. Weswegen es hauptsächlich auf die übliche Codeverbesserung und größeren DB Server hinauslief
Zum einen gibt es ja Replikations Master/Slave Methode und Clustertabelen. Davon haben wir erstmal die Hände weggelassen da wir denken dass einfach der Kommunikationsaufwand dem Nutzen bei einem BG übersteigt. Gerade mal nachgeschaut es stehen bei uns z.b. 475Mio selects zu 151 Mio schreibenden Operationen also grob 3:1 .. ungünstig :/
Wer hier erfahrungen posten könnte dass es sich trotzdem lohnt /lohnen kann bitte posten
Ansonsten gibt es noch die alternative die Datenbank semantisch in mehrere zu splitten und diese auf getrennten Server laufen zu lassen .. war uns aber zu fehleranfällig. Weswegen es hauptsächlich auf die übliche Codeverbesserung und größeren DB Server hinauslief
gepostet vor 18 Jahre, 6 Monate von Duke_
Ein guter Artikel zum Thema:
Replikation/Cluster
Was aber, wenn es an die MySQL geht. In dem Game, an dem ich bis vor kurzem mitgeschraubt habe, hatten wir testweise MySQL mit Replikation am laufen, waren aber nicht gerade sehr begeistert.
Was genau hattet ihr da eingerichtet die Master/Slave Variante also nur schreiben auf dem Master und die Slaves holen sich die Daten? Was hat euch denn nicht begeistert, weil ich mir das auch überlege.
Rein nach dem Lesen beurteilt, sieht die Master/Slave Variante für mich sehr interessant aus. In meinen Augen wäre die Arbeit dann reine Leseoperationen auf den/die Slaves zu verteilen. Leseoperationen verbunden mit Schreiboperationen dürfen nur auf dem Master ausgeführt werden. Was ich nicht weiss, ist wie lange es dauert bis der Slave sich die neuesten Daten geholt hat.
Replikation/Cluster
Original von crawling
Was aber, wenn es an die MySQL geht. In dem Game, an dem ich bis vor kurzem mitgeschraubt habe, hatten wir testweise MySQL mit Replikation am laufen, waren aber nicht gerade sehr begeistert.
Was genau hattet ihr da eingerichtet die Master/Slave Variante also nur schreiben auf dem Master und die Slaves holen sich die Daten? Was hat euch denn nicht begeistert, weil ich mir das auch überlege.
Rein nach dem Lesen beurteilt, sieht die Master/Slave Variante für mich sehr interessant aus. In meinen Augen wäre die Arbeit dann reine Leseoperationen auf den/die Slaves zu verteilen. Leseoperationen verbunden mit Schreiboperationen dürfen nur auf dem Master ausgeführt werden. Was ich nicht weiss, ist wie lange es dauert bis der Slave sich die neuesten Daten geholt hat.
gepostet vor 18 Jahre, 6 Monate von Teonas
Omega-Day verwendet meiner Ansicht nach MySQL-Replikation. Ich hab Raven mal eine PM geschrieben.
gepostet vor 18 Jahre, 6 Monate von stephan_
Hallo,
ich habe testweise Replikation mit MySQL 5 am laufen. Sprich M/S Architektur. Geschrieben und gelesen wird nur vom Master, die 2 Slaves sind also im Hot Standby und einer der beiden wuerde dann als Master nue starten. Jedoch bringt das nicht viel, da die Slaves P3 Maschinen mit 600 MHz sind, und der Master eine Sun mit einem 244 Opteron (1,8 GHz)
Aber ich bin eigentlich positiv uebrerrascht worden, was die Geschwindigkeit angeht. Als naechstes werd ich mal die Cluster Variante versuchen. Wobei ich dafuer noch mind. 1 P3 Maschine brauch, um auch den Management Knoten redundant zu halten.
Lg
Stephan Breitrainer
ich habe testweise Replikation mit MySQL 5 am laufen. Sprich M/S Architektur. Geschrieben und gelesen wird nur vom Master, die 2 Slaves sind also im Hot Standby und einer der beiden wuerde dann als Master nue starten. Jedoch bringt das nicht viel, da die Slaves P3 Maschinen mit 600 MHz sind, und der Master eine Sun mit einem 244 Opteron (1,8 GHz)
Aber ich bin eigentlich positiv uebrerrascht worden, was die Geschwindigkeit angeht. Als naechstes werd ich mal die Cluster Variante versuchen. Wobei ich dafuer noch mind. 1 P3 Maschine brauch, um auch den Management Knoten redundant zu halten.
Lg
Stephan Breitrainer
gepostet vor 18 Jahre, 6 Monate von crawling
Es mag ja ein bisschen schizzo klingen, aber mir ist entfallen, was genau das Problem an der Sache war. Ich bin mir nicht mal mehr sicher, ob es daran lag, dass der Transfer zwischen Slave und Master zu lange gedauert hat, oder ob es das Problem war, dass der Master eine Tabelle zerschossen hatte, und die Slaves sich fröhlich die Fehler mitgezogen haben, was ergo zum Totalausfall geführt hat.
Sorry ich kann gerade nicht dienen damit, was es genau war. Wenn es mir wieder einfällt werde ich es nachreichen. Aber alles in allem erscheint mir doch eine recht Interessante Diskussion entstanden zu sein, da noch mehr BG's das Problem der Erweiterung sehen.
EDIT: Allerdings muss ich noch anmerken, dass das Replikations Feature in der Version, in der wir es getestet haben, noch BETA Status hatte (hatte es das nun immer noch ? )
Sorry ich kann gerade nicht dienen damit, was es genau war. Wenn es mir wieder einfällt werde ich es nachreichen. Aber alles in allem erscheint mir doch eine recht Interessante Diskussion entstanden zu sein, da noch mehr BG's das Problem der Erweiterung sehen.
EDIT: Allerdings muss ich noch anmerken, dass das Replikations Feature in der Version, in der wir es getestet haben, noch BETA Status hatte (hatte es das nun immer noch ? )
gepostet vor 18 Jahre, 6 Monate von Kampfhoernchen
MySQL haben wir im M/S-Modus noch nicht getestet, dafür aber MaxDB. Dabei lief es eigentlich recht gut, und im Endeffekt schneller als ein Cluster. Verursacht aber logischerweise mehr Traffic. Für Cluster brauchst du mehrere gleichwertige "Mittelklasse"-Maschinen, während im M/S-Betrieb ein "dicker" Master und mehrere schwache Slaves, die jedoch eine möglichst flotte Festplatte haben sollten (deren Geschwindigkeit wird sowieso viel zu oft vernachlässigt) notwendig ist.
gepostet vor 18 Jahre, 6 Monate von raven-bs
Ich wurde per PM aufgefordert auch etwas zu schreiben . Wollt ihr also was nachfragen mailt oder PN´d mich direkt, bin normal hier nicht unterwegs im Forum...
Wir (www.Omega-Day.de) Betreiben als Datenbank aktuell 5 Server + 5 Server für die Webserver und dann halt noch Forum und Grafik/Spielengine Server.
Für eine Architektur habt ihr prinzipiell 2 große Möglichkeiten. Zum ersten könnt ihr ein Cluster verwenden (ab MySQL 5) oder wahlweise eine Replikation. Die Replikation muss aber nicht als Master/Slave ausgeführt sein, sondern kann auch eine "Zwei Wege Replikation" oder eine "Ringstruktur" sein.
Was ihr nehmen wollt liegt an eurer Anforderung. Wir in OD haben etwa 10-15 Selects auf einen Schreibenden Zugriff. Bei einem so stark liegenden Verhältnis haben wir eine Slave Variante Gewählt, die uns rein rechnerisch ermöglicht performane aus bis zu 10 Datenbank Server zu gewinnen.
Wenn die Quote geringer liegt (etwa 3-6) seit ihr wohl mir der Clusterlößung von MySQL 5 besser bedient.
Wer Ausfallsicherheit mag kann übrigens auch bei einer M/S Struktur mehrere Master Server verwenden, welche sich untereinander abgleichen.
Schwer wird es bei Select/Update qouten von <3. Dies sagt entweder aus, dass es im Gesammten sehr wehnige abfragen gibt, oder dass ihr sehr Schreiblastig seit. Ersteres ist kein Problem, nach unseren Erfahrungswerten macht ein dual Opteron etwa 2500-3000 Querys / Sekunde. das währen bei 1 Update 3 Select pro Seite 750 Pages / Sekunde.
Habt ihr aber hohe Last mit einer geringen Quote wird es haarig in meinen Augen. Dort würde ich zuerst den Hebel ansetzen updates zu sparen, oder eventuel die Datenbank in einzelne Stücke zu granulieren. Ich hab hier jetzt zwar keine Erfahrung, denke aber dass das MsSQL Cluster das besser lößen kann, da man dort jedem Clusterserver einen Präferenztabellen zuweisen kann, was man dann nur noch im Code berücksichtigen muss.
Ich berate und helfe gerne wenn jemand ein konkretes Problem hat das gelößt werden muss, schreibt mich einfach an an.
Wir (www.Omega-Day.de) Betreiben als Datenbank aktuell 5 Server + 5 Server für die Webserver und dann halt noch Forum und Grafik/Spielengine Server.
Für eine Architektur habt ihr prinzipiell 2 große Möglichkeiten. Zum ersten könnt ihr ein Cluster verwenden (ab MySQL 5) oder wahlweise eine Replikation. Die Replikation muss aber nicht als Master/Slave ausgeführt sein, sondern kann auch eine "Zwei Wege Replikation" oder eine "Ringstruktur" sein.
Was ihr nehmen wollt liegt an eurer Anforderung. Wir in OD haben etwa 10-15 Selects auf einen Schreibenden Zugriff. Bei einem so stark liegenden Verhältnis haben wir eine Slave Variante Gewählt, die uns rein rechnerisch ermöglicht performane aus bis zu 10 Datenbank Server zu gewinnen.
Wenn die Quote geringer liegt (etwa 3-6) seit ihr wohl mir der Clusterlößung von MySQL 5 besser bedient.
Wer Ausfallsicherheit mag kann übrigens auch bei einer M/S Struktur mehrere Master Server verwenden, welche sich untereinander abgleichen.
Schwer wird es bei Select/Update qouten von <3. Dies sagt entweder aus, dass es im Gesammten sehr wehnige abfragen gibt, oder dass ihr sehr Schreiblastig seit. Ersteres ist kein Problem, nach unseren Erfahrungswerten macht ein dual Opteron etwa 2500-3000 Querys / Sekunde. das währen bei 1 Update 3 Select pro Seite 750 Pages / Sekunde.
Habt ihr aber hohe Last mit einer geringen Quote wird es haarig in meinen Augen. Dort würde ich zuerst den Hebel ansetzen updates zu sparen, oder eventuel die Datenbank in einzelne Stücke zu granulieren. Ich hab hier jetzt zwar keine Erfahrung, denke aber dass das MsSQL Cluster das besser lößen kann, da man dort jedem Clusterserver einen Präferenztabellen zuweisen kann, was man dann nur noch im Code berücksichtigen muss.
Ich berate und helfe gerne wenn jemand ein konkretes Problem hat das gelößt werden muss, schreibt mich einfach an an.