Cara Mengatasi Data Terhapus Secara Tidak Sengaja di MySQL &MariaDB

Seseorang tidak sengaja menghapus bagian dari database. Seseorang lupa memasukkan klausa WHERE dalam kueri DELETE, atau mereka menjatuhkan tabel yang salah. Hal-hal seperti itu mungkin dan akan terjadi, tidak dapat dihindari dan manusiawi. Tapi dampaknya bisa menjadi bencana. Apa yang dapat Anda lakukan untuk menjaga diri dari situasi seperti itu, dan bagaimana Anda dapat memulihkan data Anda? Dalam entri blog ini, kami akan membahas beberapa kasus kehilangan data yang paling umum, dan bagaimana Anda dapat mempersiapkan diri agar dapat memulihkannya.

Persiapan

Ada beberapa hal yang harus Anda lakukan untuk memastikan pemulihan yang lancar. Mari kita pergi melalui mereka. Harap diingat bahwa ini bukan situasi "pilih satu" - idealnya Anda akan menerapkan semua tindakan yang akan kita diskusikan di bawah.

Cadangan

Anda harus memiliki cadangan, tidak ada jalan keluar darinya. Anda harus menguji file cadangan Anda - kecuali jika Anda menguji cadangan Anda, Anda tidak dapat memastikan apakah itu bagus dan apakah Anda akan dapat memulihkannya. Untuk pemulihan bencana, Anda harus menyimpan salinan cadangan Anda di suatu tempat di luar pusat data Anda - untuk berjaga-jaga jika seluruh pusat data tidak tersedia. Untuk mempercepat pemulihan, sangat berguna untuk menyimpan salinan cadangan juga di node basis data. Jika kumpulan data Anda besar, menyalinnya melalui jaringan dari server cadangan ke node database yang ingin Anda pulihkan mungkin membutuhkan waktu yang lama. Menyimpan cadangan terbaru secara lokal dapat meningkatkan waktu pemulihan secara signifikan.

Cadangan Logis

Cadangan pertama Anda, kemungkinan besar, akan menjadi cadangan fisik. Untuk MySQL atau MariaDB, itu akan menjadi sesuatu seperti xtrabackup atau semacam snapshot sistem file. Cadangan semacam itu sangat bagus untuk memulihkan seluruh kumpulan data atau untuk menyediakan node baru. Namun, dalam kasus penghapusan subset data, mereka mengalami overhead yang signifikan. Pertama-tama, Anda tidak dapat memulihkan semua data, atau Anda akan menimpa semua perubahan yang terjadi setelah cadangan dibuat. Apa yang Anda cari adalah kemampuan untuk memulihkan hanya sebagian data, hanya baris yang terhapus secara tidak sengaja. Untuk melakukannya dengan cadangan fisik, Anda harus memulihkannya di host terpisah, menemukan baris yang dihapus, membuangnya, lalu memulihkannya di kluster produksi. Menyalin dan memulihkan ratusan gigabyte data hanya untuk memulihkan beberapa baris adalah sesuatu yang pasti akan kami sebut sebagai overhead yang signifikan. Untuk menghindarinya, Anda dapat menggunakan pencadangan logis - alih-alih menyimpan data fisik, pencadangan semacam itu menyimpan data dalam format teks. Hal ini memudahkan untuk menemukan data persis yang telah dihapus, yang kemudian dapat dipulihkan langsung di kluster produksi. Untuk membuatnya lebih mudah, Anda juga dapat membagi cadangan logis tersebut menjadi beberapa bagian dan mencadangkan setiap tabel ke file terpisah. Jika kumpulan data Anda besar, masuk akal untuk membagi satu file teks besar sebanyak mungkin. Ini akan membuat pencadangan tidak konsisten tetapi untuk sebagian besar kasus, ini bukan masalah - jika Anda perlu mengembalikan seluruh kumpulan data ke keadaan yang konsisten, Anda akan menggunakan pencadangan fisik, yang jauh lebih cepat dalam hal ini. Jika Anda hanya perlu memulihkan sebagian data, persyaratan untuk konsistensi tidak terlalu ketat.

Pemulihan Point-In-Time

Pencadangan hanyalah permulaan - Anda akan dapat memulihkan data ke titik di mana pencadangan dilakukan, tetapi kemungkinan besar, data dihapus setelah waktu itu. Hanya dengan memulihkan data yang hilang dari cadangan terbaru, Anda dapat kehilangan data apa pun yang diubah setelah pencadangan. Untuk menghindarinya Anda harus menerapkan Point-In-Time Recovery. Untuk MySQL itu pada dasarnya berarti Anda harus menggunakan log biner untuk memutar ulang semua perubahan yang terjadi antara saat pencadangan dan peristiwa kehilangan data. Tangkapan layar di bawah ini menunjukkan bagaimana ClusterControl dapat membantu dengan itu.

Apa yang harus Anda lakukan adalah mengembalikan cadangan ini hingga saat sebelum kehilangan data. Anda harus memulihkannya di host terpisah agar tidak membuat perubahan pada kluster produksi. Setelah cadangan dipulihkan, Anda dapat masuk ke host tersebut, menemukan data yang hilang, membuangnya, dan memulihkannya di kluster produksi.

Budak Tertunda

Semua metode yang kami diskusikan di atas memiliki satu titik masalah yang sama - perlu waktu untuk memulihkan data. Mungkin perlu waktu lebih lama, ketika Anda memulihkan semua data dan kemudian mencoba membuang hanya bagian yang menarik. Ini mungkin memakan waktu lebih sedikit jika Anda memiliki cadangan logis dan Anda dapat dengan cepat menelusuri data yang ingin Anda pulihkan, tetapi itu sama sekali bukan tugas yang cepat. Anda masih harus menemukan beberapa baris dalam file teks besar. Semakin besar, semakin rumit tugasnya - terkadang ukuran file yang tipis memperlambat semua tindakan. Salah satu metode untuk menghindari masalah tersebut adalah memiliki budak yang tertunda. Budak biasanya mencoba untuk tetap up to date dengan tuannya tetapi juga memungkinkan untuk mengonfigurasinya sehingga mereka akan menjaga jarak dari tuannya. Pada tangkapan layar di bawah, Anda dapat melihat cara menggunakan ClusterControl untuk menyebarkan budak seperti itu:

Singkatnya, kami memiliki opsi di sini untuk menambahkan budak replikasi ke pengaturan basis data dan mengonfigurasinya untuk ditunda. Pada tangkapan layar di atas, budak akan ditunda 3600 detik, yaitu satu jam. Ini memungkinkan Anda untuk menggunakan budak itu untuk memulihkan data yang dihapus hingga satu jam dari penghapusan data. Anda tidak perlu memulihkan cadangan, cukup menjalankan mysqldump atau SELECT ... INTO OUTFILE untuk data yang hilang dan Anda akan mendapatkan data untuk dipulihkan di cluster produksi Anda.

Memulihkan Data

Di bagian ini, kita akan membahas beberapa contoh penghapusan data yang tidak disengaja dan bagaimana Anda dapat memulihkannya. Kami akan membahas pemulihan dari kehilangan data penuh, kami juga akan menunjukkan cara memulihkan dari kehilangan sebagian data saat menggunakan cadangan fisik dan logis. Kami akhirnya akan menunjukkan kepada Anda cara memulihkan baris yang terhapus secara tidak sengaja jika Anda memiliki slave yang tertunda dalam pengaturan Anda.

Data Hilang Penuh

“rm -rf” atau “DROP SCHEMA myonlyschema;” yang tidak disengaja; telah dieksekusi dan Anda berakhir tanpa data sama sekali. Jika Anda juga menghapus file selain dari direktori data MySQL, Anda mungkin perlu menyediakan ulang host. Untuk mempermudah, kami akan berasumsi bahwa hanya MySQL yang terpengaruh. Mari kita pertimbangkan dua kasus, dengan budak yang tertunda dan tanpa satu.

Tidak Ada Budak yang Tertunda

Dalam hal ini satu-satunya hal yang dapat kita lakukan adalah mengembalikan cadangan fisik terakhir. Karena semua data kami telah dihapus, kami tidak perlu khawatir tentang aktivitas yang terjadi setelah kehilangan data karena tanpa data, tidak ada aktivitas. Kita harus khawatir tentang aktivitas yang terjadi setelah pencadangan dilakukan. Ini berarti kita harus melakukan pemulihan Point-in-Time. Tentu saja akan memakan waktu lebih lama daripada hanya mengembalikan data dari cadangan. Jika membawa database Anda dengan cepat lebih penting daripada mengembalikan semua data, Anda juga dapat memulihkan cadangan dan baik-baik saja dengan itu.

Pertama-tama, jika Anda masih memiliki akses ke log biner di server yang ingin Anda pulihkan, Anda dapat menggunakannya untuk PITR. Pertama, kami ingin mengonversi bagian yang relevan dari log biner ke file teks untuk penyelidikan lebih lanjut. Kita tahu bahwa kehilangan data terjadi setelah pukul 13:00:00. Pertama, mari kita periksa file binlog mana yang harus kita selidiki:

[email protected]:~# ls -alh /var/lib/mysql/binlog.*
-rw-r----- 1 mysql mysql 1.1G Apr 23 10:32 /var/lib/mysql/binlog.000001
-rw-r----- 1 mysql mysql 1.1G Apr 23 10:33 /var/lib/mysql/binlog.000002
-rw-r----- 1 mysql mysql 1.1G Apr 23 10:35 /var/lib/mysql/binlog.000003
-rw-r----- 1 mysql mysql 1.1G Apr 23 10:38 /var/lib/mysql/binlog.000004
-rw-r----- 1 mysql mysql 1.1G Apr 23 10:39 /var/lib/mysql/binlog.000005
-rw-r----- 1 mysql mysql 1.1G Apr 23 10:41 /var/lib/mysql/binlog.000006
-rw-r----- 1 mysql mysql 1.1G Apr 23 10:43 /var/lib/mysql/binlog.000007
-rw-r----- 1 mysql mysql 1.1G Apr 23 10:45 /var/lib/mysql/binlog.000008
-rw-r----- 1 mysql mysql 1.1G Apr 23 10:47 /var/lib/mysql/binlog.000009
-rw-r----- 1 mysql mysql 1.1G Apr 23 10:49 /var/lib/mysql/binlog.000010
-rw-r----- 1 mysql mysql 1.1G Apr 23 10:51 /var/lib/mysql/binlog.000011
-rw-r----- 1 mysql mysql 1.1G Apr 23 10:53 /var/lib/mysql/binlog.000012
-rw-r----- 1 mysql mysql 1.1G Apr 23 10:55 /var/lib/mysql/binlog.000013
-rw-r----- 1 mysql mysql 1.1G Apr 23 10:57 /var/lib/mysql/binlog.000014
-rw-r----- 1 mysql mysql 1.1G Apr 23 10:59 /var/lib/mysql/binlog.000015
-rw-r----- 1 mysql mysql 306M Apr 23 13:18 /var/lib/mysql/binlog.000016

Seperti yang bisa dilihat, kami tertarik dengan file binlog terakhir.

[email protected]:~# mysqlbinlog --start-datetime='2018-04-23 13:00:00' --verbose /var/lib/mysql/binlog.000016 > sql.out

Setelah selesai, mari kita lihat isi dari file ini. Kami akan mencari 'drop schema' di vim. Berikut bagian file yang relevan:

# at 320358785
#180423 13:18:58 server id 1  end_log_pos 320358850 CRC32 0x0893ac86    GTID    last_committed=307804   sequence_number=307805  rbr_only=no
SET @@SESSION.GTID_NEXT= '52d08e9d-46d2-11e8-aa17-080027e8bf1b:443415'/*!*/;
# at 320358850
#180423 13:18:58 server id 1  end_log_pos 320358946 CRC32 0x487ab38e    Query   thread_id=55    exec_time=1     error_code=0
SET TIMESTAMP=1524489538/*!*/;
/*!\C utf8 *//*!*/;
SET @@session.character_set_client=33,@@session.collation_connection=33,@@session.collation_server=8/*!*/;
drop schema sbtest
/*!*/;

Seperti yang kita lihat, kita ingin mengembalikan ke posisi 320358785. Kita dapat meneruskan data ini ke ClusterControl UI:

Budak Tertunda

Jika kita memiliki budak yang tertunda dan host itu cukup untuk menangani semua lalu lintas, kita dapat menggunakannya dan mempromosikannya menjadi master. Namun, pertama-tama, kita harus memastikan itu menyusul master lama hingga kehilangan data. Kami akan menggunakan beberapa CLI di sini untuk mewujudkannya. Pertama, kita perlu mencari tahu di posisi mana hilangnya data itu terjadi. Kemudian kita akan menghentikan slave dan membiarkannya berjalan hingga event kehilangan data. Kami menunjukkan cara mendapatkan posisi yang benar di bagian sebelumnya - dengan memeriksa log biner. Kita dapat menggunakan posisi itu (binlog.000016, posisi 320358785) atau, jika kita menggunakan budak multithreaded, kita harus menggunakan GTID dari peristiwa kehilangan data (52d08e9d-46d2-11e8-aa17-080027e8bf1b:443415) dan memutar ulang kueri hingga GTID itu.

Pertama, mari hentikan slave dan nonaktifkan penundaan:

mysql> STOP SLAVE;
Query OK, 0 rows affected (0.01 sec)
mysql> CHANGE MASTER TO MASTER_DELAY = 0;
Query OK, 0 rows affected (0.02 sec)

Kemudian kita dapat memulainya ke posisi log biner yang diberikan.

mysql> START SLAVE UNTIL MASTER_LOG_FILE='binlog.000016', MASTER_LOG_POS=320358785;
Query OK, 0 rows affected (0.01 sec)

Jika kita ingin menggunakan GTID, perintahnya akan terlihat berbeda:

mysql> START SLAVE UNTIL SQL_BEFORE_GTIDS = ‘52d08e9d-46d2-11e8-aa17-080027e8bf1b:443415’;
Query OK, 0 rows affected (0.01 sec)

Setelah replikasi berhenti (artinya semua acara yang kami minta telah dieksekusi), kami harus memverifikasi bahwa host berisi data yang hilang. Jika demikian, Anda dapat mempromosikannya menjadi master dan kemudian membangun kembali host lain menggunakan master baru sebagai sumber data.

Ini tidak selalu merupakan pilihan terbaik. Semua tergantung pada seberapa lambat slave Anda - jika tertunda selama beberapa jam, mungkin tidak masuk akal untuk menunggu sampai selesai, terutama jika lalu lintas tulis padat di lingkungan Anda. Dalam kasus seperti itu, kemungkinan besar akan lebih cepat untuk membangun kembali host menggunakan cadangan fisik. Di sisi lain, jika Anda memiliki volume lalu lintas yang agak kecil, ini bisa menjadi cara yang bagus untuk benar-benar memperbaiki masalah dengan cepat, mempromosikan master baru dan melanjutkan melayani lalu lintas, sementara node lainnya sedang dibangun kembali di latar belakang .

Kehilangan Data Sebagian - Cadangan Fisik

Dalam kasus kehilangan sebagian data, pencadangan fisik mungkin tidak efisien, tetapi karena itu adalah jenis pencadangan yang paling umum, sangat penting untuk mengetahui cara menggunakannya untuk pemulihan sebagian. Langkah pertama akan selalu mengembalikan cadangan hingga titik waktu sebelum peristiwa kehilangan data. Juga sangat penting untuk memulihkannya di host yang terpisah. ClusterControl menggunakan xtrabackup untuk backup fisik jadi kami akan menunjukkan cara menggunakannya. Mari kita asumsikan kita menjalankan kueri yang salah berikut:

DELETE FROM sbtest1 WHERE id < 23146;

Kami ingin menghapus hanya satu baris (‘=’ dalam klausa WHERE), alih-alih kami menghapus banyak baris (

mysqlbinlog --verbose /var/lib/mysql/binlog.000003 > bin.out

Sekarang, mari kita lihat file output dan lihat apa yang bisa kita temukan di sana. Kami menggunakan replikasi berbasis baris oleh karena itu kami tidak akan melihat SQL persis yang dieksekusi. Sebagai gantinya (selama kita akan menggunakan --verbose flag ke mysqlbinlog) kita akan melihat event seperti di bawah ini:

### DELETE FROM `sbtest`.`sbtest1`
### WHERE
###   @1=999296
###   @2=1009782
###   @3='96260841950-70557543083-97211136584-70982238821-52320653831-03705501677-77169427072-31113899105-45148058587-70555151875'
###   @4='84527471555-75554439500-82168020167-12926542460-82869925404'

Seperti yang dapat dilihat, MySQL mengidentifikasi baris yang akan dihapus menggunakan kondisi WHERE yang sangat tepat. Tanda-tanda misterius dalam komentar yang dapat dibaca manusia, “@1”, “@2”, berarti “kolom pertama”, “kolom kedua”. Kita tahu bahwa kolom pertama adalah 'id', yang merupakan sesuatu yang kita minati. Kita perlu menemukan event DELETE besar pada tabel 'sbtest1'. Komentar yang akan mengikuti harus menyebutkan id 1, lalu id '2', lalu '3' dan seterusnya - semuanya hingga id '23145'. Semua harus dieksekusi dalam satu transaksi (satu peristiwa dalam log biner). Setelah menganalisis output menggunakan 'kurang', kami menemukan:

### DELETE FROM `sbtest`.`sbtest1`
### WHERE
###   @1=1
###   @2=1006036
###   @3='123'
###   @4='43683718329-48150560094-43449649167-51455516141-06448225399'
### DELETE FROM `sbtest`.`sbtest1`
### WHERE
###   @1=2
###   @2=1008980
###   @3='123'
###   @4='05603373460-16140454933-50476449060-04937808333-32421752305'

Acara yang dilampirkan komentar tersebut dimulai pada:

#180427  8:09:21 server id 1  end_log_pos 29600687 CRC32 0x8cfdd6ae     Xid = 307686
COMMIT/*!*/;
# at 29600687
#180427  8:09:21 server id 1  end_log_pos 29600752 CRC32 0xb5aa18ba     GTID    last_committed=42844    sequence_number=42845   rbr_only=yes
/*!50718 SET TRANSACTION ISOLATION LEVEL READ COMMITTED*//*!*/;
SET @@SESSION.GTID_NEXT= '0c695e13-4931-11e8-9f2f-080027e8bf1b:55893'/*!*/;
# at 29600752
#180427  8:09:21 server id 1  end_log_pos 29600826 CRC32 0xc7b71da5     Query   thread_id=44    exec_time=0     error_code=0
SET TIMESTAMP=1524816561/*!*/;
/*!\C utf8 *//*!*/;
SET @@session.character_set_client=33,@@session.collation_connection=33,@@session.collation_server=8/*!*/;
BEGIN
/*!*/;
# at 29600826

Jadi, kami ingin mengembalikan cadangan hingga komit sebelumnya di posisi 29600687. Ayo lakukan sekarang. Kami akan menggunakan server eksternal untuk itu. Kami akan memulihkan cadangan hingga ke posisi itu dan kami akan menjaga server pemulihan tetap berjalan sehingga kami dapat mengekstrak data yang hilang nanti.

Setelah pemulihan selesai, mari kita pastikan data kita telah dipulihkan:

mysql> SELECT COUNT(*) FROM sbtest.sbtest1 WHERE id < 23146;
+----------+
| COUNT(*) |
+----------+
|    23145 |
+----------+
1 row in set (0.03 sec)

Kelihatan bagus. Sekarang kita dapat mengekstrak data ini ke dalam file yang akan kita muat kembali di master.

mysql> SELECT * FROM sbtest.sbtest1 WHERE id < 23146 INTO OUTFILE 'missing.sql';
ERROR 1290 (HY000): The MySQL server is running with the --secure-file-priv option so it cannot execute this statement

Ada yang tidak beres - ini karena server dikonfigurasi untuk dapat menulis file hanya di lokasi tertentu - ini semua tentang keamanan, kami tidak ingin pengguna menyimpan konten di mana pun mereka suka. Mari kita periksa di mana kita dapat menyimpan file kita:

mysql> SHOW VARIABLES LIKE "secure_file_priv";
+------------------+-----------------------+
| Variable_name    | Value                 |
+------------------+-----------------------+
| secure_file_priv | /var/lib/mysql-files/ |
+------------------+-----------------------+
1 row in set (0.13 sec)

Oke, mari kita coba sekali lagi:

mysql> SELECT * FROM sbtest.sbtest1 WHERE id < 23146 INTO OUTFILE '/var/lib/mysql-files/missing.sql';
Query OK, 23145 rows affected (0.05 sec)

Sekarang terlihat jauh lebih baik. Mari kita salin data ke master:

[email protected]:~# scp /var/lib/mysql-files/missing.sql 10.0.0.101:/var/lib/mysql-files/
missing.sql                                                                                                                                                                      100% 1744KB   1.7MB/s   00:00

Sekarang saatnya memuat baris yang hilang pada master dan menguji apakah berhasil:

mysql> LOAD DATA INFILE '/var/lib/mysql-files/missing.sql' INTO TABLE sbtest.sbtest1;
Query OK, 23145 rows affected (2.22 sec)
Records: 23145  Deleted: 0  Skipped: 0  Warnings: 0

mysql> SELECT COUNT(*) FROM sbtest.sbtest1 WHERE id < 23146;
+----------+
| COUNT(*) |
+----------+
|    23145 |
+----------+
1 row in set (0.00 sec)

Itu saja, kami memulihkan data kami yang hilang.

Kehilangan Data Sebagian - Cadangan Logis

Di bagian sebelumnya, kami memulihkan data yang hilang menggunakan cadangan fisik dan server eksternal. Bagaimana jika kita telah membuat cadangan logis? Mari lihat. Pertama, mari kita verifikasi bahwa kita memiliki cadangan logis:

[email protected]:~# ls -alh /root/backups/BACKUP-13/
total 5.8G
drwx------ 2 root root 4.0K Apr 27 07:35 .
drwxr-x--- 5 root root 4.0K Apr 27 07:14 ..
-rw-r--r-- 1 root root 2.4K Apr 27 07:35 cmon_backup.metadata
-rw------- 1 root root 5.8G Apr 27 07:35 mysqldump_2018-04-27_071434_complete.sql.gz

Ya, itu ada. Sekarang, saatnya untuk mendekompresinya.

[email protected]:~# mkdir /root/restore
[email protected]:~# zcat /root/backups/BACKUP-13/mysqldump_2018-04-27_071434_complete.sql.gz > /root/restore/backup.sql

Ketika Anda melihat ke dalamnya, Anda akan melihat bahwa data disimpan dalam format INSERT multi-nilai. Misalnya:

INSERT INTO `sbtest1` VALUES (1,1006036,'18034632456-32298647298-82351096178-60420120042-90070228681-93395382793-96740777141-18710455882-88896678134-41810932745','43683718329-48150560094-43449649167-51455516141-06448225399'),(2,1008980,'69708345057-48265944193-91002879830-11554672482-35576538285-03657113365-90301319612-18462263634-56608104414-27254248188','05603373460-16140454933-50476449060-04937808333-32421752305')

Yang perlu kita lakukan sekarang adalah menunjukkan dengan tepat di mana tabel kita berada dan kemudian di mana baris, yang menarik bagi kita, disimpan. Pertama, mengetahui pola mysqldump (letakkan tabel, buat yang baru, nonaktifkan indeks, masukkan data) mari kita cari tahu baris mana yang berisi pernyataan CREATE TABLE untuk tabel 'sbtest1':

[email protected]:~/restore# grep -n "CREATE TABLE \`sbtest1\`" backup.sql > out
[email protected]:~/restore# cat out
971:CREATE TABLE `sbtest1` (

Sekarang, dengan menggunakan metode coba-coba, kita perlu mencari tahu di mana mencari baris kita. Kami akan menunjukkan kepada Anda perintah terakhir yang kami buat. Seluruh triknya adalah mencoba dan mencetak rentang garis yang berbeda menggunakan sed dan kemudian memeriksa apakah baris terbaru berisi baris yang mendekati, tetapi lebih lambat dari yang kita cari. Pada perintah di bawah ini kami mencari baris antara 971 (CREATE TABLE) dan 993. Kami juga meminta sed untuk berhenti setelah mencapai baris 994 karena sisa file tidak menarik bagi kami:

[email protected]:~/restore# sed -n '971,993p; 994q' backup.sql > 1.sql
[email protected]:~/restore# tail -n 1 1.sql  | less

Outputnya terlihat seperti di bawah ini:

INSERT INTO `sbtest1` VALUES (31351,1007187,'23938390896-69688180281-37975364313-05234865797-89299459691-74476188805-03642252162-40036598389-45190639324-97494758464','60596247401-06173974673-08009930825-94560626453-54686757363'),

Ini berarti bahwa rentang baris kami (hingga baris dengan id 23145) dekat. Selanjutnya, ini semua tentang pembersihan file secara manual. Kami ingin memulai dengan baris pertama yang perlu kami pulihkan:

INSERT INTO `sbtest1` VALUES (1,1006036,'18034632456-32298647298-82351096178-60420120042-90070228681-93395382793-96740777141-18710455882-88896678134-41810932745','43683718329-48150560094-43449649167-51455516141-06448225399')

Dan berakhir dengan baris terakhir untuk memulihkan:

(23145,1001595,'37250617862-83193638873-99290491872-89366212365-12327992016-32030298805-08821519929-92162259650-88126148247-75122945670','60801103752-29862888956-47063830789-71811451101-27773551230');

Kami harus memangkas beberapa data yang tidak dibutuhkan (ini adalah penyisipan multiline) tetapi setelah semua ini kami memiliki file yang dapat kami muat kembali di master.

[email protected]:~/restore# cat 1.sql | mysql -usbtest -psbtest -h10.0.0.101 sbtest
mysql: [Warning] Using a password on the command line interface can be insecure.

Akhirnya, pemeriksaan terakhir:

mysql> SELECT COUNT(*) FROM sbtest.sbtest1 WHERE id < 23146;
+----------+
| COUNT(*) |
+----------+
|    23145 |
+----------+
1 row in set (0.00 sec)

Semuanya baik-baik saja, data telah dipulihkan.

Kehilangan Data Sebagian, Budak Tertunda

Dalam hal ini, kami tidak akan melalui seluruh proses. Kami telah menjelaskan cara mengidentifikasi posisi peristiwa kehilangan data dalam log biner. Kami juga menjelaskan cara menghentikan slave yang tertunda dan memulai replikasi lagi, hingga titik sebelum peristiwa kehilangan data. Kami juga menjelaskan cara menggunakan SELECT INTO OUTFILE dan LOAD DATA INFILE untuk mengekspor data dari server eksternal dan memuatnya di master. Itu saja yang Anda butuhkan. Selama data masih pada budak tertunda, Anda harus menghentikannya. Kemudian Anda perlu menemukan posisi sebelum peristiwa kehilangan data, mulai budak hingga titik itu dan, setelah ini selesai, gunakan budak yang tertunda untuk mengekstrak data yang telah dihapus, salin file ke master dan muat untuk mengembalikan data .

Kesimpulan

Memulihkan data yang hilang tidak menyenangkan, tetapi jika Anda mengikuti langkah-langkah yang kami lalui di blog ini, Anda akan memiliki peluang bagus untuk memulihkan apa yang hilang.