Нещо много важно: Правете си задължително бекъп за да не изпадате в тази ситуация. Повярвайте ми на всеки се случва да си затрие базата. Аз винаги съм си мислил, че колкото трябва да си загубен да си затриеш базата, но уви и на мен се случи.
Още един съвет: Не се опитвайте да триете таблица от базата данни когато говорите по телефона или правите нещо друго !!!
Ако недай боже ви се случи да си затриете базата без да имате бекъп може да постъпите по няколко начина. Предварително искам да ви кажа, че не мога да гарантирам, че те ще са удобни за вас, на мен специално единия ми свърши работа.
Възтановяване на базата данни от bin-logs
В този момент е от значителна важност е да имате такива, защото аз поради някаква необяснима причина съм ги спрял, но защо? Съветвам ви винаги да си пазите такива. И ако все пак нямате такива логове по-доло съм ви описал какво да правите тогава.
Понеже аз нямах такива логове веднага започнах да търся друго решение и затова не мога да ви дам културно решение, но ще се опитам да ви дам няколко линка които биха могли да помогнат.
- http://www.linuxjournal.com/content/recover-mysql-table-zmanda-recovery-manager
- http://www.webdevelopmentstuff.com/129/mysql-drop-database-recovery.html
Искренно се надявам нещо от тези материали да ви свърши работа.
Възтановяване на базата данни от файловата система
Ето този начин на мен ми свърши работа, на 95% останалите 5 процента си ги възтанових от queries от кода.
Сега тук има малко удивителни „!!!“.
Ако искате да възтановите InnoDB таблици от цялата база можете да използвате този тул : InnoDB Data Recovery tool
Ако го използвате обаче имайте в предвид, че няма да ви помогне за възтановяването на MyISAM таблиците. Тоест ако в същата директория имате някой от следните MYD / .MYI / .frm, тоест MyISAM всички те ще бъдат брутално затрити.
Така за рестор от самата файлова система има 2 много полезни тула които биха ви свършили работа, ако сте късметлии и днес не е петък 13-ти :)
Ето и самите тулове:
- http://code.google.com/p/ext3grep/
- http://www.xs4all.nl/~carlo17/howto/undelete_ext3.html – документация как да използвате ext3grep tool-чето
- TestDisk – една от опциите му е да възтановява файлове.
Аз лично не стигнах до TestDisk, защото ext3grep успя да ми свърши работата.
Ето няколко начина по които използвах ext3grep за да си постигна целта.
Първо вижте от кой дял или диск ще възтановявате информация:
dev:~# mount /dev/hda1 on / type ext3 (rw,errors=remount-ro) tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755) proc on /proc type proc (rw,noexec,nosuid,nodev) sysfs on /sys type sysfs (rw,noexec,nosuid,nodev) procbususb on /proc/bus/usb type usbfs (rw) udev on /dev type tmpfs (rw,mode=0755) tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=620) dev:~#
След това можете да се опитате да възтановите целия дял:
ext3grep /dev/hda1 --restore-all --accept-all
Понже така възтановяватве файлове от време оно, ако искате да възтановите файлове от определен момент, можете да направите следното:
ext3grep /dev/hda1 --restore-all --accept-all --after 1258738238 --before 1258738238
Ако ви мързи като мен да напишете няколко реда и да си изпринтите тези чисълца, които означават определен момент от времето (година, дата, час, мин и тнт. ) можете да използвате този online тул: http://www.functions-online.com/mktime.html
Понеже, поради някакви кофти сектори в харда на едно място ми се чупеше постоянно и винаги преди /var/log/mysql/ където ми се съхраняват базите данни. За това се присетих да подходя по малко по различен начин.
Понеже ext3grep има една много полезна опция да ти дъмпне всички имена на файлове които намери във файловата система реших да видя какво мога да направя:
ext3grep /dev/hda1 --dump-names > ext3grep.log
Понеже ext3grep принти много информация, забих аутпут-а да влиза в един лог файл от който полсе ще си взема имената на файловете които искам да възтановя. Трябва да изчакате цялата процедура да свърши, но имайте в предвид, че може да се забави доста, за това не се шашкайте.
След като цялата процедура завърши можете да си вземете всички файлове и един по един да ги ресторнете. Понеже мен ме мързи, защото базата ми имаше над 40 таблици направих написах няколко реда за да свършат работата вместо мен.
Ето така си взех нужните таблици:
cat ext3grep.log |grep 'mysql/mydatabase' > mytablefiles
За да ги възтановя си написах простичко баш скриптче:
#!/bin/bash
files=`cat mytablefiles`
for file in $files
do
ext3grep /dev/hda1 --restore-file $file
done
#ext3grep /dev/hda1 --restore-file var/lib/mysql/mytable/users.MYI - Това е командата за възтановяване!
След това правим файла изпълним и го пускаме да ходи да си бачка, което става най-лесно така:
chmod +x restore_script && ./restore_script
Сега тук нещо много важно!
Първо: еxt3grep създава един файл hda1.ext3grep.stage1 (в моя случай) в който си записва разни неща. Не ви препоръчвам да го триете след първото обхождане на файловата система. Ако случайно стане някаква грешка или искате да направите друго обхождане и пр. можете да си го изтриете.
Второ: Всички възтановени файлове се шибат в една папка която софтуерчето си създава в папката в която сте го пуснали. Тази папка се казва така : RESTORED_FILES . Тоест ако сте пуснали скрипта когато сте се намирали в /root/, RESTORED_FILES/ ще се появи точно там, /root/RESTORED_FILES/. Ако нямате идея каде се намирате в момента pwd ще ви каже това.
Трето: След като възтановите файловете и ги копирате по най-грубия начин в папката на mysql-а в моя случай /var/lib/mysql/ не забравяйте да си оправите пермишъните, защото mysql няма да си познае базичката или по скоро таблиците в нея. За да видим с какъв потребител и с коя група върви мysql можем да направим следното:
dev:~# ls -la /var/lib/mysql total 28772 drwxr-xr-x 10 mysql mysql 4096 2009-11-21 01:04 . drwxr-xr-x 28 root root 4096 2009-11-20 20:18 .. -rw-r--r-- 1 root root 0 2009-01-18 00:13 debian-5.0.flag drwx------ 2 mysql mysql 12288 2009-06-15 22:12 dotproject -rw-rw---- 1 mysql mysql 18874368 2009-11-21 01:06 ibdata1 -rw-rw---- 1 mysql mysql 5242880 2009-11-21 01:06 ib_logfile0 -rw-rw---- 1 mysql mysql 5242880 2009-11-21 01:05 ib_logfile1 drwxr-xr-x 2 mysql root 4096 2009-11-21 00:34 mysql -rw------- 1 root root 6 2009-01-18 00:13 mysql_upgrade_info drwx------ 2 root root 12288 2009-06-15 22:12 mytable drwx------ 2 mysql mysql 4096 2009-01-31 21:40 wiki drwx------ 2 mysql mysql 4096 2009-11-03 00:49 wordpress dev:~#
Горе доло от тук ни стана ясно, че mysql върви с mysql:mysql, което означава, че трябва да ги сменим на нашата ново прехвърлена база, защото по пътя на логиката те трябва да са root:root. Ето как може да стане това:
chown -R mysql:mysql /var/lib/mysql/mytable
И след целия този цирк при мен всичко си запали, без онези 5% за които ви споменах.
Е надявам се да съм бил полезен. Ако нещо не сте разбрали драснете някой ред, ще се опитам да помогна.
Още веднъж, ще се радвам ако съм успял да помогна на някой и съм спестил доста време в мъки и чудене :)
Етикети: dropped mysql table recovery, MySQL, mysql drop recovery, recover dropped mysql, recover mysql table, връщане на изтрита база, възтановяване на изтрит mysql, възтановяване на изтрита база данни
[...] MySQL база данни под Linux, ако я изтрием и нямаме бекъп? http://m.ignev.net/blog/databases/mysql/11_21…ut-backup/ в Любими преди 1 минута edno23.com Начало контакти [...]