Reiz arī Tev pienāks tā diena, kad MySQL rezerves kopijas izveide aizņems ilgu laiku, jo datubāžu un tabulu apjomi būs pieauguši. Un tad Tu sapratīsi, ka mysqldump, mysqlsnapshot u.c. aizņem pārāk ilgu laiku. Un arī datu failu kopēšana vairs nav drošs pasākums. Apstādināt serveri uz šo laiku arī nav prāta darbs.

Tad nu nāk talkā risinājums, kurš manām vajadzībām (DB apjoms jau sen ir mērāms gigabaitos un sistēmai nav pieļaujams downtime) ir kā radīts.

Jums taču ir backup serveris, ne? Ja nav, tad iegādājiet. Noderēs.

Uz tā uzlieciet MySQL. Nokonfigurējiet backupojamo serveri, kā replikācijas “māsteri”. Tas darās ar vienu-divām rindiņām iekš my.cnf. Uz backup servera esošu MySQL, savukārt, nokonfigurējiet kā replikācijas “sleivu”.

Un tad jau jūs varat veidot snapšotus, pilnos datubāzes dampus un citas štelles, izmantojot kā izejas materiālu informāciju, kura ir “sleivā”.

Pie kam, problēmu (atteices:) gadījumā ir iespējams ātri nokonfigurēt “sleivu” par “māsteru”.

Sākot ar MySQL 4.1 4.0 uz “sleiva” var palaist komandu LOAD DATA FROM MASTER. Tas tad, ja ir labs savienojums starp abiem serveriem un ir pieņemami read locki uz visām datubāžu tabulām. Pretējā gadījumā, kā jau minēju - jātaisa snapshoti. Tie arī ģenerēs read lockus, bet darīs to uz īsāku laika brīdi.

Papildināts. Gan LOAD DATA FROM MASTER, gan mysqlsnapshot ir problēmas, ja pirmajā reizē replicējamo datu ir daudz. Abās reizēs pārāk dikti nolokojas viss serveris. Mēģināsim vēlreiz vakarā.

P.S. Sorry. Viens ir vedējserveris, bet otrs - sekotājserveris. Un ir pilnās datubāžu izmetes, nevis dumpi. Un momentuzņēmumi, nevis snapshoti. Un dublējumi (dublējumserveri), nevis rezerves kopijas, vai backupi.