Replikation via copy /var/lib/mysql

[arachon]

Hallo,

ich habe folgende Ausgangslage:

* mySQL 4.0.26

Server A (Development-Maschine) -> Anwendung erzeugt mySQL Daten (DB-Grösse ca. 1 GB)

Server B (Webserver) -> soll mySQL Daten von Server A verfügbar machen

Habe bisher "mysqldump" und "mysql < datenbank123.sql" probiert - dauert aber extrem lange beim Einspielen der Daten auf Server B


Daher folgende Frage:
Kann ich die Datenbank auch replizieren, wenn ich ganz einfach die Dateien aus z.B. /var/lib/mysql/datenbank123 kopiere ?

Also beispielsweise:

Backup Server A:
1) mysqld auf Server A stoppen
2) Dateien mit tar in ein Archiv (datenbank123.tar)
3) mysqld auf Server A wieder starten

Einspielen Server B:
1) Archivdatei datenbank123.tar auf Server B kopieren
2) mysqld stoppen
3) Archiv nach /var/lib/mysql/datenbank123 auspacken, bestehende Tabellen überschreiben
4) mysqld wieder starten


Die o.a. Prozedur würde nur einen Bruchteil der Zeit kosten, mit einer kleinen Test-Datenbank habe ich es bereits probiert - scheint auch funktioniert zu haben.

Gibt es irgendetwas, was ich nicht bedacht habe ? Z.b. einen generellen Index o.ä., der dann nicht mehr stimmt, wenn man einfach einige neue Tabellen "drüberbügelt" ? Auf dem Webserver laufen auch noch andere Datenbanken, die NICHT überschrieben und geändert werden sollen... Daher scheint auch die im Manual erwähnte Replikation (-> http://dev.mysql.com/doc/refman/4.1/en/replication.html) eher nicht möglich.


Danke !

[oxygen]

Native Replikation funktioniert einwandfrei auch mit nur einer Datenbank. Von dem kopieren würde ich absehen.

[pedä]

Native Replikation funktioniert einwandfrei auch mit nur einer Datenbank. Von dem kopieren würde ich absehen.

gibts da auch einen besonderen grund für, oder sagst das einfach nur so???

denn ich betreibe das kopieren, von dem du absehen würdest, bereits seit ca. drei jahren bisher absolut (!!) problemlos sogar bei laufendem datenbank-server!

(sicherungskopien der ausgangspositionen und ausgangstabellen selbstverständlich vorhanden, bisher aber nie benötigt!)

[pedä]

Hallo,
Habe bisher "mysqldump" und "mysql < datenbank123.sql" probiert - dauert aber extrem lange beim Einspielen der Daten auf Server B

such mal nach "Bigdump.php" ist eine nette variante, um große dumps einzuspielen!

[flo]

Habe bisher "mysqldump" und "mysql < datenbank123.sql" probiert - dauert aber extrem lange beim Einspielen der Daten auf Server B

Schau Dir die Manpage zu mysqldump an und sieh zu, wo Du sparen kannst - Kompression würde sich da anbieten.

Beim Kopieren der Datenbanken hast Du das Problem, daß Du evtl. inkonsistente Daten rumkopierst - daß Du den Daemon vorher stoppst, ist ja schon löblich. Ich würde außerdem keinen funktionierenden wichtigen Dienst einfach so herunterfahren, wenn davon eventuell Systemfunktionen und Websites abhängen.

Ganz davon abgesehen ist auch nicht gesagt, ob de kopierten Datenbankfiles zwischen verschiedenen Versionen auch noch austauschbar wären, d.h. Du müsstest auf Deiner Development-Kiste immer die gleiche MySQL-Version fahren wie auf Deinem Produktivserver.

Angesichts Deiner Datenmenge ist die native Replikation natürlich auch insofern besser, als daß Du nicht jedesmal einen großen Brocken überflüssiger Daten rumschiebst, sondern dies häppchenweise passiert.

flo.

[isotopp]

Kann ich die Datenbank auch replizieren, wenn ich ganz einfach die Dateien aus z.B. /var/lib/mysql/datenbank123 kopiere ?

"Replikation" ist in MySQL ein besonderer Begriff mit einer besonderen Bedeutung.

Ich vermute, Du meinst das NICHT, sondern willst Daten von Server A nach Server B kopieren, indem Du die Datenbankdateien aus $datadir/<datenbankname> von Server A nach Server B kopierst.

Das ist möglich. Diese Datenbankdateien sind portabel.

Wenn es sich um MyISAM-Tabellen handelt, musst Du entweder den Server runterfahren oder FLUSH TABLES WITH READ LOCK machen, um alle Daten auf die Platte zu zwingen und kannst dann die Dateien kopieren. Danach den Server neu starten oder UNLOCK TABLES.

Wenn es sich um InnoDB Tables handelt, musst Du den Server runterfahren und kannst dann die InnoDB Tablespace Files kopieren. Danach den Server wieder starten. FLUSH TABLES WITH READ LOCK geht nicht mit InnoDB.

Wenn Du inkrementelle Live-Updates willst, solltest Du Dich mit Master-Slave Replikation auseinandersetzen. Insbesondere über die do-db und ignore-db Filter solltest Du Dich einmal nachlesen.

MySQL 4.0 ist sehr alt und ist die nächste MySQL Version, die aus der Wartung läuft. Sie wird nicht mehr weiterentwickelt und bekommt auch keine Bugfixes mehr, sondern nur noch Security Fixes. Du kannst leicht ein aktuelles MySQL tar-gz installieren (in /usr/local/) und parallel zum oder anstatt des System-MySQL betreiben.

[isotopp]

... dauert aber extrem lange beim Einspielen der Daten auf Server B

Wieviel Hauptspeicher?
Größe des mysqld in der Prozeßliste?
key_buffer in der my.cnf?
myisam_sort_buffer_size in der my.cnf?

[arachon]

@all:
Danke für die zahlreichen Beiträge. Werde mir wohl auch die Replication genauer ansehen.

@isotopp:
Hauptspeicher: 2 GB
key_buffer_size = 64M
sort_buffer_size = 4M
read_buffer_size = 1M
myisam_sort_buffer_size = 8M

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
16341 mysql 16 0 24572 23m 3764 R 94.0 1.2 0:33.59 mysqld-max
16340 root 11 0 1300 1300 1088 S 17.5 0.1 0:08.23 mysql

Das ganze zieht - obwohl der Dump nicht riesig gross ist - enorme Ressourcen. Dahingehend ist das ganze quick'n'dirty mit dem Kopieren der Files wesentlich ressourcenschonder - der mv Befehl ist in wenigen Sekunden erledigt, somit ist auch der Ausfall des mysqld minimal...

[isotopp]

@isotopp:
Hauptspeicher: 2 GB
key_buffer_size = 64M
sort_buffer_size = 4M
read_buffer_size = 1M
myisam_sort_buffer_size = 8M

Dein Hauptspeicher nutzt Dir nur dann datenbanktechnisch was, wenn Du MySQL erlaubst, ihn auch zu benutzen. Wieviel Hauptspeicher willst Du MySQL geben?

In der Annahme, daß Du neben MySQL noch andere Sachen auf dem Server laufen lassen möchtest, kannst Du nicht mit den ganzen 2GB für MySQL arbeiten. Wenn Du aber mehr als triviale Dinge auf Deiner MySQL-Kommandozeile machen willst, sind die angezeigten 23M Prozeßgröße zu klein.

key_buffer_size ist der Speicher, den MySQL verwendet, um MyISAM-Indices zu im Speicher cachen. Es ist also nicht sinnvoll, den Key Buffer größer als die Summe Deiner MYI-Dateien (die stehen in $datadir, also meist in /var/lib/mysql) zu machen, bzw. größer als die Summe der "Index Length"-Angaben bei "SHOW TABLE STATUSG". Es ist auch nicht sinnvoll, den Key Buffer größer als 20-30% des Hauptspeichers zu machen, da dem System noch Platz bleiben muss, Daten aus den MYD-Dateien zu cachen, und dafür wird der betriebssystemeigene Filesystem Cache gebraucht.

Nehmen wir mal an, Dein System fährt hauptsächlich MySQL und Apache und Du willst Deinem System so ca. 500M Hauptspeicher für MySQL zuordnen, weil Du eine richtig große Datenbank hast, dann solltest Du den Key Buffer auf bis zu 400M sizen (es gibt noch weitere Puffer in MySQL, und die können auch nützlich sein).

Mehr zu lesen: http://dev.mysql.com/doc/refman/5.0/en/ ... cache.html
(bzw. was immer die für Dich zutreffende Version ist)

Der bulk_insert_buffer wird von MySQL beim Einlesen von durch mysqump erzeugten Daten verwendet (allgemeiner: http://dev.mysql.com/doc/refman/5.0/en/ ... ables.html, dort bulk_insert_buffer_size). Es ist eine Session-Variable, kann also für jede Connection individuell und on-the-fly gesetzt werden.

Du kannst also

Code: Select all

mysql> select @@session.bulk_insert_buffer_size as b;
+----------+
| b        |
+----------+
|  8388608 |
+----------+
1 row in set (0.00 sec)
mysql> set @@session.bulk_insert_buffer_size=50*1024*1024;
Query OK, 0 rows affected (0.00 sec)
mysql> source mydump.sql
...

machen. Der myisam_sort_buffer wird bei REPAIR TABLE und CREATE INDEX/ALTER TABLE verwendet. Auch dieser Puffer kann per Session gesetzt werden. Ich bin mir aber ohne auf den Code zu sehen gerade nicht sicher, ob der Dir auch noch was bringt. Wenn Speicher vorhanden ist, drehe auch diesen Puffer vor dem Einlesen des mysqldump noch mal hoch. Mit dem Ende des Kommandozeilenclients endet auch Deine Session und damit werden diese beiden Puffer wieder freigegeben.

Bitte beachte, daß sich diese Angaben alle auf ein MyISAM-System beziehen. Für InnoDB werden andere Variablen verwendet.

[flo]

Das ist möglich. Diese Datenbankdateien sind portabel.

Geht das auch zwischen verschiedenen Versionen?
flo.

[isotopp]

Geht das auch zwischen verschiedenen Versionen?
flo.

Dazu musst Du die Release Notes lesen. Die MYD sind überwiegend unkritisch, aber die MYI sind komplizierter. Das Problem ist im wesentlichen, daß 4.0 zum Beispiel genau gar nix von Zeichensätzen und Collations weiß, und daß in 4.1 und 5.0 in einigen Releases die Collations fehlerkorrigiert worden sind. Damit sortiert Dein Zielsystem dann falsch, wenn Du die Indices nicht droppst und neu erzeugst.