Die Ausführung des Befehls kann je nach Größe der Datenbank von einigen Sekunden bei zu mehreren Minuten Dauern. Bei sehr großen Datenbanken auch Stunden. Ist der Vorgang jedoch abgeschlossen, findet man im aktuellen Verzeichnis den Dump. Diesen kann man nun auf den Server kopieren, wo die Datenbank läuft, in welche man den Export importieren möchte. Dies kann man per SCP oder per SFTP machen, wie einem beliebt.

Hat man nun also die Datei kopiert, wechselt man auf die Konsole des Zielservers. Dort geht man dann in das Verzeichnis, in welchem die Datei liegt. Hier nun folgendes Kommando absetzen:

Hiermit wird die Datenbank aus der Datei in den MySQL-Server importiert. Zu beachten sei, das Datenbanken gleichen Namens so überschrieben werden. Ist dies erfolgreich abgeschlossen kann man die SQL-Datei löschen.

Einfache Replikation: Master – Slave

Für eine asynchrone Replikation werden mindestens 2 MySQL-Server benötigt, von denen einer als Master und mindestens einer als Slave agiert. Bei dieser Art von Replikation schreibt der Master die Updates (alle Statements, die Datensätze verändern) in eine Binärlog-Datei. Diese dient als Datenspeicher, von welchem aus die Informationen über Datenänderungen an die Slave-Server gesendet werden.

Sobald sich ein Slave mit dem Master verbindet, übermittelt dieser die Position der letzten, erfolgreich empfangenen Änderungen, und empfängt daraufhin vom Master alle Updates seit der übermittelten Position. Nachdem der Slave die Änderungen übernommen hat, schaltet er so zu sagen in den Leerlauf und wartet auf die Übermittlung weiterer Änderungen vom Master.

Konfiguration eines Master

Für den später einzurichtenden Slave muss man auf dem Master einen Account anlegen. Dies erledigt man mit einen GRANT-Befehl, welcher allgemein dazu da ist Benutzer anzulegen. „GRANT SUPER,REPLICATION CLIENT,REPLICATION SLAVE ON *.* TO ReplikationsUser@slavehost IDENTIFIED BY ‘PWD’ ; Flush Privileges;“. Wobei hier dann „@slavehost“ die IP oder der Hostname des Slave ist. Man sollte dann noch in der „my.cnf“ nachsehen ob eine „server-id“ vergeben ist. Ohne diese geht es nicht. Jeder Server, der an einer Replikation beteiligt ist, braucht eine eindeutige „server-id“. Dabei sind nur Zahlen erlaubt. Man sollte dann auch noch einen Verbindungstest durchführen, indem man sich vom Slave aus auf den Master verbindet. „mysql -h masterhost -u ReplikationsUser -p“. Sollte diese Verbindung nicht aufgebaut werden können, sollte man beim Master kontrollieren ob in der Konfig evtl. „bind-address = 127.0.0.1“ steht oder ob das Passwort richtig gesetzt ist. Im folgenden Schritt erstellt man dann eine Kopie aller zu replizierenden Daten. Im Regelfall ist das meist alles. Dafür sperrt man den kompletten Server mit einer Schreib-Sperre.

„FLUSH TABLES WITH READLOCK ;“. Die Konsole in der man dies Kommando eingegeben hat muss für die Dauer der folgenden Vorgänge geöffnet bleiben, da sonst der Readlock erlischt. Um dem Slave die genaue Position und den Namen der Binärlogdatei mitzuteilen, führt man noch folgendes Kommando aus: „SHOW MASTER STATUS;“. Die Ausgabe sollte dabei dieser ähneln:

[ Mit den letzten beiden Feldern kann man in der „my.cnf“ explizit festlegen, welche einzelnen Datenbanken repliziert werden sollen und welche nicht. Dieses sollte man aber im Regelfall nie auf dem Master festlegen. Sondern eher auf dem Slave filtern. Dort kann man auch wieder in der „my.cnf“ festlegen was alles repliziert werden soll und was nicht. ]

Man notiert sich nun den Namen des „binlog“ und die Position, danach kann man mit dem Kopieren der Daten beginnen. Hat man nur MyISAM-Datenbanken macht man dies am besten auf Dateiebene. „tar -cvz -f /backup/mysql/snapshot_DATUM.tar.gz /var/lib/mysql“. Um die DB nicht all zu lange zu sperren kann man auch erst nur die Daten kopieren und dann später komprimieren. Ist man dann fertig, kann man sich aus der MySQL-Konsole ausloggen und somit die Sperre wieder aufheben.

Konfiguration eines Slave

Die MySQL-Version auf dem Slave sollte mindestens der des Masters entsprechen. Sie darf neuer sein, aber nicht älter. Auf dem Slave stoppt man dann erstmal den laufenden MySQL-Server und editiert die „my.cnf“. Dort setzt man auch wieder die Variablen für die Server-ID. Zu beachten ist hier nur, dass die Server-ID sich von der des Masters und aller bestehenden Slaves unterscheiden muss. Will man, das dieser Slave noch Master für weitere untergeordnete Slaves ist, muss man auch darauf achten das hier das binlog aktiviert ist. Hat man dann die Daten, welche man auf dem Master kopiert hat übertragen, kopiert man diese auf dem Slave nach „/var/lib/mysql“. Zu beachten sei, das man sich nicht die Datenbank „mysql“ überschreibt. Diese sollte man auch in der „my.cnf“ von der Replikation ausnehmen. Dies macht man mit den Optionen:

replicate-ignore-db= mysql
replicate-wild-ignore-table = mysql.%

Hat man dann die Daten kopiert, kontrolliert man noch mal, ob alle Dateien unterhalb von „/var/lib/mysql“ auch dem Benutzer und der Gruppe „mysql“ gehören. Jetzt kann man den MySQL-Server wieder starten. Um nun die Replikation zu aktiveren müssen wir dem Slave noch mitteilen, wer der Master ist und an welcher Stelle im binlog er anfangen soll zu lesen. Dies macht man mit dem „CHANGE MASTER“ Kommando:

Wurde das Statement erfolgreich ausgeführt, wurden alle Änderungen übernommen und der Slave ist soweit bereit die Replikation zu starten. Gestartet wird dann einfach mit „SLAVE START;“ (gestoppt mit „SLAVE STOP;“). Nach dem Start sollte man mit „SHOW SLAVE STATUS;“ den Status der Replikation überprüfen. Steht „Slave_IO_Running“ auf „Yes“ läuft die Replikation. Dann ist immer noch der Wert „Seconds_Behind_Master“ interessant. Er gibt an, wie viel der Slave dem Master hinterher hängt. Am Anfang steht hier eine mehr oder weniger große Zahl, in endlicher Zeit sollte hier dann aber nur noch „0“ stehen. Steht dort „NULL“ gibt es ein Problem mit der Replikation, dann ist aber auch „Slave_IO_Running“ meisten auf „No“. Unter „Last_Error“ kann man dann noch nachlesen, wieso es zu einer Unterbrechung kam.

Reparieren der Replikation

Sollte die Replikation einmal unterbrochen werden, sollte man mit „slave stop“ erst mal den Replikations Prozess beenden. Mit „slave show status\G“ kann man sich dann den Status ausgeben lassen. Hierbei sollte man jetzt auf die Zeile „Last_Error:“ achten. Die dort ausgegebene Fehlermeldung sollte man nun genauer untersuchen und versuchen festzustellen warum es zu diesen Fehler kam. Hat man diesen dann beseitigt kann man mit „SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1;“ MySQL anweisen, dieses Query zu überspringen. Anschließend kann man mit „slave start“ die Replikation wieder starten. Wenn alles gut läuft und dies der einzigste Fehler war, müsste diese nun auch wieder laufen.

Master – Master

Bei einer Master-Master-Replikation, gibt es, wie der Name schon sagt, 2 Master. Beide sind sich gegenseitig aber noch Slave. Sodas Änderungen auf einen Master direkt auch auf dem 2. Verfügbar sind und umgekehrt. Bei Master Slave kommen Update immer nur von einer Seite, vom Master. Hier kann jeder der beiden Änderungen machen. Dies führt natürlich auch zu Probleme. Was ist, wenn beide den gleichen Datensatz Ändern wollen? Deswegen muss man hier sehr auf die Daten-Integrität achten und am besten immer nur einen der Beiden Master schreiben lassen.

Aufbau einer Master-Master-Replikation

Es muss hier auch wieder auf beiden Server von den Gleichen Daten ausgegangen werden. Auf beiden das „binlog“ aktiviert sein. Dann kann man auf beiden jeweils einen Slave-Prozess einrichten, welcher den anderen Als Master nimmt.

Der Aufbau von MySQL ist recht Simple. Die einzige Konfigurationsdatei liegt in „/etc/mysql/“ und heißt „my.cnf“. Hier lassen sich nun die verschiedenen Laufzeitoptionen von MySQL einstellen. Zum Beispiel auf welchen Port und welchen Interface es laufen soll. Aber auch wieviel Puffer und Speicher MySQL verwenden soll. Die eigentlichen Daten von MySQL werden dann in „/var/lib/mysql“ gespeichert. Das Rechte-Management von MySQL wird über eine MySQL-Datenbank mit dem Namen „mysql“ gesteuert.

„my.cnf“

Die „my.cnf“ ist in mehrere Teil gegliedert. Jeder Teilbereich wird durch den Namen eckige Klammer abgegrenzt. Der wirklich wichtige Bereich ist „[mysqld]“. Dort stehen die Optionen welche für den MySQL-Prozess wichtig sind. Hier man eine gute Grundkonfiguration:

Server Basics

Am Anfang sollte man immer Grundlegende Dinge festlegen. Wie z.B. den Buntzer, unter welchen MySQL laufen soll. Soll es an eine IP gebunden werden? Welcher Port verwendet werden soll. Wichtig für die Replikation ist dann auch immer eine eindeutige „server-id“. Oft ist es auch sinnvoll „Selects“ eine höhere Priorität zu geben. „skip-locking“ sollte auf jeden Fall aktiviert sein, da sonst die Performance massiv einbrechen kann. Ohne diese Option werden recht rechenintensive Methoden verwendet, Tabellen von der Festplatte zu lesen.

Server Verzeichnisse und Logdateien

Im weiteren Verlauf der Konfig werde meist noch mehrere Verzeichnisse und Log-Dateien definiert. Diese sind selbsterklärend. Einzig auf das „bin-log“ sollte man genau achten, da darüber die Replikation abläuft. „datadir“ ist, wo die Tabellen auf der Festplatte abgelegt werden.

Puffer und Caches

MySQL hat verschiedene Cache-Funktionen und Puffer. Manche sind nur auf Verbindungsebene aktive, wieder andere serverweit. Aber es geht auch, das man auf seiner Verbindung den Cache/Puffer neu definiert und so den Serverweiten überschreibt, für seine Verbindung. Cache und Puffer kann man nie pauschal festlegen. Sie müssen auf die jeweiligen Anwendungen angepasst werden, welche mit der Datenbank arbeiten sollen.

Bei „max_connections“ handelt es sich um die Anzahl der offenen Verbindungen, oder eingeloggten Benutzer wenn man so will.

„open_files_limit“ gibt an, wieviele Dateien der MySQL-Prozess gleichzeitig öffnen darf.

„long_query_time“ wird in Sekunden angegeben. Es definiert ab welcher laufzeit ein Query als „slow query“ eingestuft wird.

„thread_cache_size“ gibt die Anzahl der Threads an, welche zurückgehalten werden.

„query_cache_szie“ legt die Größe des Speichers für SELECT-Querys fest.

„query_cache_limit“ besagt, das Querys, welche größer als das Limit sind, nicht gecached werden sollen.

„table_cache“ gibt die Anzahl an Tabellen vor, welche im Speicher gehalten werden sollen.

„max_heap_table_size“ gibt an, wie groß eine Tabellen sein darf, welche temporär im RAM erzeugt wird.

„tmp_table_size“ legt die gesamt Größe des Tabellen-Cache fest.

„read_buffer_size“ ist für das sequenzielle auslesen von Tabellen zuständig. Werte größer als 512 KB bringen kaum mehr Performance.

„key_buffer_size“ legt die Größe des Speichers für die MyISAM Key-Files der Tabellen fest. Man sollte möglichst versuchen viel davon im Speicher zu haben.

„read_rnd_buffer_size“ ist für nicht-sequenzielle und parallele Zugriffe auf Tabellen zuständig.

„join_buffer_size“, wie der Name schon da, um bei „joins“ zwischen zu speichern.

„sort_buffer_size“, beim Sortieren ist dieser Puffer wichtig.

Installationsdialog von MAMP

Nachdem man es nun installiert hat kann man es einfach starten. Danach fragt es sofort, auch wenn man die normale Version genommen hat, ob man nicht die Pro-Version nehmen mag. Dies verneint man dann und kommt ins normal kleine Interface von MAMP. Gleichzeitig öffnet sich auch noch ein Browser-Fenster in dem die “Weboberfläche” von MAMP öffnet. Hier hat man einmal die PHPInfo-Informationen und einen phpMyAdmin, sowie einige allgemeine Informationen.

MAMP Interface

Hier in dem Interface kann man nun die Server starten und beenden. Einige wenige Grundeinstellungen können noch unter “Einstellungen…” getroffen werden. Wie z.B. ob die Server beim starten sofort gestartet werden sollen und ob beim starten gefragt werden soll, ob man nicht doch die Pro-Version haben mag. Weiterhin können die Ports, auf welchen die Server laufen sollen, eingestellt werden. Sowie kann man die PHP-Version einstellen und definieren wo das Documentroot des Apache sein soll.

Optionen von MAMP

Und wenn die Server dann von allein starten und durch manuelles klicken auf “Server starten” ist man auch schon fertig. Unter “localhost:8888″ ist der Apache zu erreichen und über “localhost:8889″ der MySQL-Server. Hat man die aufgegangen Weboberfläche von MAMP geschlossen kann man diese durch klicken auf “Startseite öffnen” wieder holen.

So, das wärs dann also….

Hier noch eine Auflistung des kompletten inhalts von MAMP:

Gestern haben wir uns dann mal einen VServer erstellt, also ne VM die ich bereit stellte und darauf eine Domain geschalten. Dann alles nach und nach installiert. Eigentlich sollten wir ja nicht soviel eingreifen müssen, da wir ja viele scripte vorbereitet hatten. Dies war aber ein Irrtum. Das meiste lief ganz gut durch, also Apache, MySQL und PHP. Postfix ging auch ganz gut durch. Doch dann die Konfiguration davon. Da gab es dann doch das ein oder andere Problem, was isch dann aber auch lösen lies. Meist waren es kleine Fehler mit grossen Auswirkungen wie eben falsche Dateiberechtigungen oder Datenbankberechtigungen. Eines der Grösseren Probleme war, das die ClamAV Version von Debian wohl einen Tick hat und in der Konfiguration, so wie ich sie hier hatte, nicht richtig funktionierte. Nach ein wenig Recherche im Netz fand ich dann aber einen passenden Workaround.
So gegen 23 Uhr war dann alles soweit erstmal bereit das es lief. Also ein Webserver mit PHP und MySQL support, MySQL an sich und eine Mailserverkonstrukt, was Emails empfangen und verenden kann. Wir hatten um 12:00 Uhr Mittags angefangen. Naja, mal ne grössere Pause zum einkaufen und noch eine weitere zum essen. Was jetzt dann noch fehlte waren so Kleinigkeiten wie die Richtige Verschlüsselung der Mails und Statistik tools wie AwStats und Cacti. Auch sollte noch ein Jabber-Server hinzukommen. Dies haben wir dann noch bis 4 Uhr morgens implementiert. Als Jabber Server hatten wir uns dann für OpenFire entschieden, aufgrund der GUI. Is ja für Mausschubser, aber falls eben mal kein Admin zu Hand ist, das die auch mal ein wenig was regeln können. Dann noch als Test für den Webserver und PHP sowie MySQL noch eben ein kleines WordPress aufgesetzt um zu sehen ob das läuft.

Ich werde dann mal Demnächst die Final Version der Script-Sammlung hier noch veröffentlichen.

hier dann noch ein paar quellen:

HowtoForge Tutorial für einen Mail Server

Workaround Tutorial für einen Mail Server