[MySQL] Backup strategie

[-FoX-]

Ik probeer een goed beeld te krijgen over de backup mogelijkheden en strategieën van MySQL, daar ik deze database wil gaan gebruiken in een productieomgeving (engine=InnoDB).

De meest simpele manier is door volgend commando natuurlijk:

code:

mysqldump --tab=/path/to/dir --opt db_name

Maar als een database vollop in gebruik is, zal dit geen consistente oplossing zijn. Zeker niet als de dump een aantal minuten zal duren. Ik las iets in de mysql help over LOCK TABLES, FLUSH TABLES, maar gelijkertijd ook iets over het feit dat dit problemen kon geven daar de lock bij de volgende transactionele actie alweer opgeheven werd.

Verder moet het natuurlijk ook mogelijk zijn om een recovery procedure te starten; op welke manier kan ik hier het best mee omgaan? Graag zou ik ten alle tijden willen vermijden dat er ook maar 1 byte aan data verloren zal gaan, zelfs in een worst-case-scenario. Kan dit

Wat als al mijn tabellen en zelfs database corrupt zijn; een re-install noodzakelijk is. Ik kan dan natuurlijk de dump terug zetten, maar zijn er nog andere manieren van recovery?

Alle tips zijn welkom; op welke manieren kan er een efficiente backup strategie bekomen worden

[elevator]

Enkel een backup procedure en "nooit ook maar 1 byte verloren laten gaan" gaan sowieso al niet samen, je komt dan op tenminste mirroring technieken uit volgens mij?

Verder - voor een consistente view lijkt de optie "--single-transaction" mij voldoende:

quote: http://dev.mysql.com/doc/refman/5.0/en/mysqldump.html

This option issues a BEGIN SQL statement before dumping data from the server. It is useful only with transactional tables such as InnoDB and BDB, because then it dumps the consistent state of the database at the time when BEGIN was issued without blocking any applications.

When using this option, you should keep in mind that only InnoDB tables are dumped in a consistent state. For example, any MyISAM or MEMORY tables dumped while using this option may still change state.

The --single-transaction option and the --lock-tables option are mutually exclusive, because LOCK TABLES causes any pending transactions to be committed implicitly.

This option is not supported for MySQL Cluster tables; the results cannot be guaranteed to be consistent due to the fact that the NDBCluster storage engine supports only the READ_COMMITTED transaction isolation level. You should always use NDB backup and restore instead.

To dump large tables, you should combine this option with --quick.

[Aike]

Misschien is dit topic ook interessant voor je. Grote mysql database dumpen geeft teveel load

[-FoX-]

In dat topic wordt er vanuitgegaan dat het een MyISAM database is, dus niet echt helemaal relevant.

Dan wordt het commando:

code:

mysqldump --tab=/path/to/dir --opt db_name --single-transaction

Kan ik er dan wel zeker van zijn dat er op dat moment geen data meer naar de tabellen geschreven wordt?

The --single-transaction option and the --lock-tables option are mutually exclusive, because LOCK TABLES causes any pending transactions to be committed implicitly.

Op welke manier moet ik dit interpreteren? Een LOCK TABLES (of -lock-tables) gaat ervoor zorgen dat alle transacties impliciet gecommit worden?? Dan kan de db toch erg gemakkelijk inconsistent worden?!

Buiten het dumpen van de database naar een file, zijn er nog andere mogelijkheden tot backup?

En wat dan met de recovery procedures?

[-FoX-]

Ik kwam vandaag het volgende script tegen:
MySQL Backup

Heeft er iemand al gebruik van gemaakt?
Ziet er op het eerste zicht wel OK uit...