Pencadangan dan pemulihan MySQL

Ada dua cara utama untuk mencadangkan database MySQL: fisik dan logis. Cadangan fisik menyalin file data sebenarnya dan cadangan logis menghasilkan pernyataan seperti CREATE TABLE dan INSERT yang dapat membuat ulang data.

Cadangan fisik berisi salinan mentah dari semua file dan direktori saat ada di disk. Jenis cadangan ini cocok untuk database besar karena menyalin file mentah jauh lebih cepat dibandingkan dengan mengambil cadangan logis.

Kelebihan:

• Pencadangan fisik sangat mudah dan efisien; tidak membutuhkan banyak memori atau banyak siklus CPU untuk dijalankan

• Pencadangan fisik tidak memerlukan pekerjaan tambahan untuk menghasilkan file mentah; yang perlu Anda lakukan hanyalah menyalin file dan direktori mentah ke lokasi cadangan

• Pencadangan fisik lebih cepat dipulihkan daripada pencadangan logis karena MySQL tidak perlu membuat ulang objek database dan mengimpor data

Kekurangan:

• Pencadangan fisik sering kali membutuhkan lebih banyak ruang daripada cadangan logis karena berisi log transaksi, log urung, dan lain-lain, selain tablespace InnoDB (yang digunakan bersama dan per file table.ibd dan biasanya memiliki ruang yang terfragmentasi)

• Pencadangan fisik tidak selalu portabel di seluruh platform, sistem operasi, dan versi MySQL

• Karena cadangan fisik menyalin file mentah, jika ada kerusakan yang mendasar, hal tersebut juga akan disalin ke file cadangan

Beberapa alat pencadangan fisik umum di seluruh ekosistem MySQL

• Pencadangan MySQL Enterprise 
• Percona XtraBackup 
• MariaDB Mariabackup

Cadangan logis berisi data dalam database dalam bentuk yang dapat ditafsirkan MySQL sebagai SQL atau sebagai teks terbatas. Fungsi ini adalah representasi database Anda sebagai urutan pernyataan SQL yang dapat dieksekusi untuk membuat ulang objek database dan mengimpor data. Jenis cadangan ini cocok untuk database kecil karena cadangan logis dapat memakan waktu pemulihan yang jauh lebih lama daripada memulihkan cadangan fisik. Jenis cadangan ini juga berguna saat bermigrasi ke atau dari layanan database terkelola di cloud.

Kelebihan:

• Pencadangan logis sangat fleksibel. Pencadangan ini menawarkan tingkat perincian yang tinggi pada operasi pencadangan dan pemulihan di tingkat server (semua database), tingkat database (semua tabel dalam database tertentu), tingkat tabel, atau bahkan tingkat baris (baris tabel yang cocok dengan kondisi WHERE). 

• Pencadangan logis lebih mudah dipulihkan. Cukup masukkan file cadangan ke klien mysql dan gunakan pernyataan LOAD DATA atau perintah mysqlimport untuk memuat file yang dibatasi teks.

• Pencadangan logis dapat dijalankan dari jarak jauh dari komputer yang berbeda, sehingga Anda dapat mencadangkan dan memulihkan database di seluruh jaringan. Hal ini sangat berguna untuk database cloud seperti Google Cloud SQL, Amazon RDS, dan Microsoft Azure tempat pengguna tidak memiliki akses langsung ke virtual machine.

• Pencadangan logis membantu menghindari kerusakan data. Cadangan fisik dapat rusak, yang dapat tidak terlihat hingga verifikasi. Karena pencadangan logis biasanya berupa file teks, akan lebih mudah untuk meninjaunya dengan editor teks dan menemukan kerusakan. Pencadangan logis jarang rusak.

• Tidak seperti pencadangan fisik, pencadangan logis sangat portabel di seluruh platform, sistem operasi, dan versi MySQL. 

• Pencadangan logis sangat mudah dikompresi.

Kekurangan:

• Pencadangan logis lebih lambat dibuat, karena Anda perlu mengkueri server MySQL untuk mendapatkan skema dan baris, lalu mengonversinya ke format logis

• Pencadangan logis juga lebih lambat dipulihkan, karena MySQL perlu mengeksekusi pernyataan SQL untuk membuat tabel, mengimpor baris, dan membangun ulang indeks

• Dibandingkan dengan pencadangan fisik, pencadangan logis memerlukan lebih banyak resource server (CPU, RAM, dan I/O disk) untuk operasi pencadangan dan pemulihan

Beberapa alat pencadangan logis umum

• mysqldump
• mydumper
• mysqlpump

Utilitas shell MySQL — dump | beban

Seperti namanya, pemulihan point-in-time membantu Anda memulihkan instance ke titik waktu tertentu. Misalnya, jika error menyebabkan hilangnya data, Anda dapat memulihkan database ke statusnya sebelum error terjadi.

PITR adalah proses dua langkah, yang bergantung pada log biner:

1. Pulihkan cadangan fisik atau logis penuh untuk mengembalikan server ke status yang sama seperti pada saat pencadangan 
2. Terapkan log biner untuk memutar ulang perubahan antara waktu pencadangan dan titik waktu yang diinginkan

Log biner berisi perubahan yang dilakukan pada instance database, seperti membuat tabel, menyisipkan/memperbarui/menghapus baris, dan lainnya. Misalnya, pencadangan harian Anda berjalan pada pukul 06.00 dan Anda ingin dapat memulihkan instance kapan saja hingga pukul 10.15. Untuk memulihkan status Anda pada pukul 10.15, Anda harus memulihkan cadangan penuh terlebih dahulu dari pukul 06.00, lalu Anda akan memutar ulang peristiwa log biner dari pukul 06.00 hingga 10.15. Langkah ini akan membawa server ke status yang diinginkan pada waktu yang diinginkan.

Log biner diperlukan untuk replikasi dan PITR; log biner sama pentingnya dengan data yang mendasarinya. Log biner perlu dicadangkan secara real time agar efektif dalam perencanaan pemulihan Anda, dan Anda dapat mendownloadnya menggunakan perintah mysqlbinlog.

Contoh:

The <binlog_filename> akan menjadi file pertama yang didownload, dan mysqlbinlog akan otomatis beralih ke file berikutnya setelahnya. Log biner tersebut ditulis di direktori server saat ini yang menjalankan perintah mysqlbinlog. Anda dapat mengubah nama dan lokasi file menggunakan opsi --result-file. Anda juga dapat menggunakan opsi --stop-never untuk mengaktifkan binlog mysqlbinlog agar tetap terhubung ke server dan mendownload perubahan baru saat ditulis.

Anda dapat mempelajari lebih lanjut dari panduan mysqlbinlog tentang cara terhubung ke server jarak jauh dan mendownload log biner sebagaimana yang ditulis.

Sebagai layanan database terkelola Google Cloud untuk MySQL, Cloud SQL menawarkan pencadangan otomatis dan pemulihan point-in-time (PITR) untuk perlindungan data. Fitur ini diaktifkan secara default dan diperlukan untuk mengaktifkan ketersediaan tinggi (HA) pada instance Cloud SQL untuk MySQL. 

Setiap pencadangan Cloud SQL merupakan jenis pencadangan fisik, karena merupakan snapshot yang diambil di Persistent Disk (PD). Cloud SQL menawarkan fleksibilitas untuk membuat pencadangan terjadi secara otomatis, atau Anda dapat mengambilnya secara on-demand kapan saja. Anda tetap dapat mengambil pencadangan logis dengan menggunakan alat pencadangan logis MySQL standar, seperti mysqldump, mydumper, mysqlpump, dan lainnya tanpa mengganggu pencadangan terkelola. 

Mari pelajari cara kerja cadangan Cloud SQL.

Cloud SQL menggunakan Persistent Disk (PD) untuk penyimpanan, dan setiap instance Cloud SQL memiliki disk data persisten terpasang untuk menyimpan file dan direktori database.

Cloud SQL menggunakan snapshot PD untuk pencadangan, dan snapshot tersebut merujuk pada status disk data pada titik waktu tertentu. Snapshot pertama PD adalah snapshot lengkap yang berisi semua data tentang PD, snapshot berikutnya bersifat inkremental dan hanya berisi data baru atau data yang dimodifikasi sejak snapshot sebelumnya. Anda dapat menganggap snapshot ini sebagai salinan fisik persistent data disk yang dikelola cloud dan merupakan dasar dari semua fitur pencadangan dan pemulihan Cloud SQL, termasuk PITR.

Cloud SQL menjalankan dua jenis pencadangan terkelola: otomatis dan on demand. Kedua jenis pencadangan tersebut disimpan di lokasi multi-region yang paling dekat dengan instance secara default. Misalnya, jika instance Cloud SQL Anda berada di us-central1, cadangan Anda akan disimpan di multi-region AS secara default. Namun, lokasi default seperti australia-southeast1 berada di luar multi-region dan akan ditempatkan di multi-region terdekat, yaitu asia. Anda juga dapat memilih lokasi kustom untuk cadangan.

Pencadangan otomatis

Pencadangan otomatis dilakukan setiap hari selama periode 4 jam pilihan Anda. Pencadangan dimulai selama periode pencadangan dan dapat berlanjut di luar periode pencadangan hingga prosesnya selesai. Anda dapat mengonfigurasi jumlah cadangan otomatis yang akan dipertahankan, dari 1 hingga 365. Kebijakan retensi default-nya adalah mempertahankan tujuh cadangan terbaru.

Pencadangan sesuai permintaan

Anda juga dapat membuat pencadangan secara on-demand kapan saja. Hal ini berguna jika Anda memerlukan cadangan dan tidak ingin menunggu periode pencadangan. Selain itu, tidak seperti pencadangan otomatis, cadangan on-demand tidak dihapus secara otomatis. Pesan akan tetap ada sampai Anda menghapusnya atau sampai instance-nya dihapus.

Anda dapat memulihkan cadangan ke instance yang sama tempat cadangan tersebut diambil atau ke instance lain dalam project yang sama. Perhatikan bahwa instance target tidak boleh berupa replika baca itu sendiri dan tidak boleh memiliki replika baca pada saat memulihkan cadangan. Hal ini karena replika baca adalah salinan dari instance utama dan menimbulkan risiko bahwa replika akan tidak sinkron dengan yang utama. Setelah itu, Anda dapat menambahkan replika baca kapan saja.

Jika cadangan dipulihkan, PD baru akan dibuat dari snapshot cadangan tersebut dan menghubungkannya ke instance. Database mulai menggunakan disk baru dan melakukan proses pemulihan error MySQL standar sebelum online sebagai database MySQL lengkap yang baru dipulihkan dari snapshot.

Memulihkan ke instance yang sama

Saat Anda melakukan pemulihan dari cadangan ke instance yang sama, Anda mengembalikan data pada instance tersebut ke statusnya saat Anda membuat cadangan. 

Memulihkan ke instance yang berbeda

Saat Anda melakukan pemulihan dari cadangan ke instance lain, Anda akan memperbarui data pada instance target ke status instance sumber saat Anda mengambil cadangan.

Penting: Memulihkan cadangan akan menimpa semua data terkini pada instance target, termasuk log pemulihan point-in-time sebelumnya. Data yang ditimpa tidak dapat dipulihkan.

Di Cloud SQL, PITR selalu membuat instance baru yang mewarisi setelan instance sumber, mirip dengan operasi clone instance. Fitur ini mengharuskan pencadangan otomatis dan pemulihan point-in-time (log biner) diaktifkan di instance sumber. Kebijakan retensi default di log biner adalah 7 hari, dan Anda dapat mengonfigurasi periode retensi data dari 1 hingga 7 hari.

PITR dicapai dengan membuat instance baru dari cadangan instance asli dan memutar ulang log biner yang disimpan pada disk data instance asli ke titik tertentu. 

Saat melakukan PITR di Cloud SQL, pelanggan dapat memilih untuk meng-clone status instance saat ini atau meng-clone ke stempel waktu di masa lalu. 

UI untuk melakukan PITR akan terlihat seperti berikut.