MySQL Synchronisieren
- Ersteller sd12
- Erstellt am
Maik
Angesehenes Mitglied
MySQL bietet von sich aus diese Möglichkeit, nennt sich Replikation:
http://dev.mysql.com/doc/refman/5.1/de/rep...tion-intro.html
Im prinzip konfiguriert man einen MySQL Server als Master, die anderen als Slave, und von da an braucht man sich um nix mehr zu kümmern.
http://dev.mysql.com/doc/refman/5.1/de/rep...tion-intro.html
Im prinzip konfiguriert man einen MySQL Server als Master, die anderen als Slave, und von da an braucht man sich um nix mehr zu kümmern.
Sascha Ahlers
Legendäres Mitglied
Theoretisch habe ich mich damit beschäftigt, da ich das Thema nicht nur interessant finde, sondern auch gut gebrauchen kann.
Bei den Kosten kommt es darauf an, was man genau haben möchte, das kann bei zwei einfachen Servern anfangen, und nach oben sind dann kaum Grenzen gesetzt.
MfG Sascha Ahlers
Bei den Kosten kommt es darauf an, was man genau haben möchte, das kann bei zwei einfachen Servern anfangen, und nach oben sind dann kaum Grenzen gesetzt.
MfG Sascha Ahlers
TSc
Legendäres Mitglied
QUOTE (Sascha Ahlers @ So 25.6.2006, 22:40) Bei den Kosten kommt es darauf an, was man genau haben möchte, das kann bei zwei einfachen Servern anfangen, und nach oben sind dann kaum Grenzen gesetzt.
Also so wie bei allem im Leben.
Hast du irgendwo was zu der Leistungsfähigkeit eines solchen Clustersystems gefunden? Ohne wird es schwer den Bedarf und die benötigte Größe abzuschätzen...
Also so wie bei allem im Leben.
Hast du irgendwo was zu der Leistungsfähigkeit eines solchen Clustersystems gefunden? Ohne wird es schwer den Bedarf und die benötigte Größe abzuschätzen...
Sascha Ahlers
Legendäres Mitglied
QUOTE (TSc @ Mo 26.6.2006, 7:29)Hast du irgendwo was zu der Leistungsfähigkeit eines solchen Clustersystems gefunden? Ohne wird es schwer den Bedarf und die benötigte Größe abzuschätzen...
Nun, ein einfaches Cluster (in der billigen Variante) kann nur eine lesende Last nehmen, und nur kurzzeitig eine schreibende Last.
Darum ist es besonders wichtig bereits bei der Programmierung darauf zu achten, dass das Programm entpsprechend flexibel ist. Der Spruch, eine Query Optimierung kann meistens das System um das 1000 fache beschleunigen, aber eine Hardwareanschaffung meistens nicht mal um das 10 fache. Nur das alleine ist nicht damit gemeint "bei der Programmierung darauf zu achten", denn es geht auch darum, dass man die Tabellen im Rahmen des möglichen flexibel aufteilen kann.
Bei nichtzureichender Programmierung könnte SQLRelay etwas behilflich sein, es mag ein gutes Programm sein, ist aber kein Allheilmittel. Ansonsten muss man sich halt einen entsprechenden ausgestatten gemeinsamen Speicher zulegen, in Form eines NAS oder besser eines (FC) SANs. Zumindestens mit dem letztenderen explodieren aber die Kosten auch gleich wieder, dafür ist es aber wieder sehr flexibel und auch später noch erweiterbar.
Also kann je ein gutes Clustersystem vermutlich, je nach Hardware und Flaschenhals, die Last bei zwei Geräten gut um fast die Hälfte reduzieren, hat also die doppele Leistung. Bei drei dann auf ein Drittel usw. Beim einfachen Master-Slave-System gilt das nur lesend, und beim einen guten Master-Master-System auch schreibend, dafür muss jedoch auch der gemeinsame Speicher mitspielen, wenn nämlich dort dann der Flaschenhals ist, wird es nicht so viel sein.
Wenn das Master-Master-System ohne gemeinsamen Speicher arbeitet, kann man nur kurzzeitig eine etwas größere Last bewältigen, beide System haben aber letztendlich gleich viel zu tun, womit auch die Leistung nicht gesteigert werden würde, sondern höchstens die Ausfallsicherheit.
Pauschal lässt sich das aber leider nicht so beantworten, weil einfach zu viele Faktoren damit reinspielen, darum habe ich die Beschreibung oben allgemein gehalten. Um es genauer sagen zu können, müsste man wesendlich mehr Informationen haben und eine entsprechende Erfahrung mit der Replikation, so wie mit dem System, welches darauf betrieben werden soll.
MfG Sascha Ahlers
Nun, ein einfaches Cluster (in der billigen Variante) kann nur eine lesende Last nehmen, und nur kurzzeitig eine schreibende Last.
Darum ist es besonders wichtig bereits bei der Programmierung darauf zu achten, dass das Programm entpsprechend flexibel ist. Der Spruch, eine Query Optimierung kann meistens das System um das 1000 fache beschleunigen, aber eine Hardwareanschaffung meistens nicht mal um das 10 fache. Nur das alleine ist nicht damit gemeint "bei der Programmierung darauf zu achten", denn es geht auch darum, dass man die Tabellen im Rahmen des möglichen flexibel aufteilen kann.
Bei nichtzureichender Programmierung könnte SQLRelay etwas behilflich sein, es mag ein gutes Programm sein, ist aber kein Allheilmittel. Ansonsten muss man sich halt einen entsprechenden ausgestatten gemeinsamen Speicher zulegen, in Form eines NAS oder besser eines (FC) SANs. Zumindestens mit dem letztenderen explodieren aber die Kosten auch gleich wieder, dafür ist es aber wieder sehr flexibel und auch später noch erweiterbar.
Also kann je ein gutes Clustersystem vermutlich, je nach Hardware und Flaschenhals, die Last bei zwei Geräten gut um fast die Hälfte reduzieren, hat also die doppele Leistung. Bei drei dann auf ein Drittel usw. Beim einfachen Master-Slave-System gilt das nur lesend, und beim einen guten Master-Master-System auch schreibend, dafür muss jedoch auch der gemeinsame Speicher mitspielen, wenn nämlich dort dann der Flaschenhals ist, wird es nicht so viel sein.
Wenn das Master-Master-System ohne gemeinsamen Speicher arbeitet, kann man nur kurzzeitig eine etwas größere Last bewältigen, beide System haben aber letztendlich gleich viel zu tun, womit auch die Leistung nicht gesteigert werden würde, sondern höchstens die Ausfallsicherheit.
Pauschal lässt sich das aber leider nicht so beantworten, weil einfach zu viele Faktoren damit reinspielen, darum habe ich die Beschreibung oben allgemein gehalten. Um es genauer sagen zu können, müsste man wesendlich mehr Informationen haben und eine entsprechende Erfahrung mit der Replikation, so wie mit dem System, welches darauf betrieben werden soll.
MfG Sascha Ahlers