Backup und replikation

könnte es sein, oder besser: unter welchen Szenarien wäre es
vorstellbar, dass Inserts in die Master-DB, die schiefgehen, weil ein
doppelter Key besteht, die Replikation aufhalten dH die Replikation zu
den Clients wird wegen dem Fehler auch gestoppt? Ich _glaube_ solche
Fälle (ganz selten) zu haben, und kann mir die Ursache nicht erklären.


Wenn die Replikation funkt, mach ich zuerst ein
mysqlhotcopy ... --noindexes --allowold replikatdb hotbackupdb
also von der replizierten Datenbank, und danach ein
mysqldump ... hotbackupdb
_ohne_ davor die indexes zu fixen.
(alles myisam tables)
Nach meinem dafürhalten funktioniert mysqldump auch mit den "kaputten"
indexes, aber kann man sich drauf verlassen ...?

W

Re: Backup und replikation

Werner bauer wrote:
> könnte es sein, oder besser: unter welchen Szenarien wäre es=20
> vorstellbar, dass Inserts in die Master-DB, die schiefgehen, weil ein=20
> doppelter Key besteht, die Replikation aufhalten dH die Replikation zu=20
> den Clients wird wegen dem Fehler auch gestoppt? Ich _glaube_ solche=20
> Fälle (ganz selten) zu haben, und kann mir die Ursache nicht erkläre=
n.

Nein, in diesem Fall wird die Replikation nicht gestoppt, da der
fehlgeschlagene INSERT gar nicht erst ins binary log wandert.=20

Die Replikation wird dann angehalten, wenn das Ergebnis auf dem
Master und auf dem Slave unterschiedlich ist, wenn also z.B. ein
INSERT auf dem Master funktioniert hat, auf dem Slave aber ein
doppelter Keywert aufgetreteten ist. Das ist aber normalerweise ein
Indiz dafuer, dass etwas prinzipielles nicht stimmt (Initialabgleich
nicht 100% identisch oder es gibt schreibende Clients auf dem Slave
(wobei letzteres kein Problem ist, wenn man weiss, was man tut)).

Re: Backup und replikation

Werner bauer wrote:
>
> Wenn die Replikation funkt, mach ich zuerst ein
> mysqlhotcopy ... --noindexes --allowold replikatdb hotbackupdb
> also von der replizierten Datenbank, und danach ein
> mysqldump ... hotbackupdb
> _ohne_ davor die indexes zu fixen.
> (alles myisam tables)

Warum so kompliziert? Wenn das ein Replikat extra fürs Backup ist,
kannst du doch direkt einen Dump davon ziehen (oder mit mysqlhotcopy
wegkopieren). Bleibt die Replikation (genauer: der SQL-Thread) halt
so lange stehen.

Außerdem halte ich ein mysqlhotcopy ohne Indizes für ziemlich witzlos.
Der Vorteil der Direktkopie (auch gegenüber einem Dump) ist ja, daß
das Restore sehr schnell geht - es müssen keine Indizes geprüft und/
oder neu aufgebaut werden. Das bisschen extra Zeit zum kopieren der
Indexfiles sollte man schon aufbringen. Wichtig für gute Performance
ist, für Quelle und Ziel von mysqlhotcopy physikalisch getrennte
Festplatten zu verwenden.

> Nach meinem dafürhalten funktioniert mysqldump auch mit den "kaputten"
> indexes, aber kann man sich drauf verlassen ...?

Je nach verwendeten Optionen geht das in die Hose. Z.B. kann mysqldump
die Daten sortiert nach PRIMARY KEY rausschreiben...


XL