Bagian penting untuk mencegah segala jenis kehilangan data dalam situasi apa pun adalah memiliki kebijakan pencadangan dan pemulihan yang sesuai. Penting juga untuk memastikan pemulihan data kapan saja dalam siklus hidup alur kerja aplikasi. Baik MySQL dan MariaDB menawarkan solusi untuk kasus ini. Artikel ini akan mengeksplorasi opsi dan prosedur yang ada serta opsi cadangan potensial lainnya untuk MySQL dan MariaDB.
Strategi Cadangan
Karena data adalah bagian terpenting dari aplikasi apa pun, melindungi integritasnya sangat penting untuk bertahan dalam pertempuran eksistensi. Gangguan apa pun terhadap aksesibilitas atau integritas data sewaktu-waktu kemungkinan akan sangat merugikan aplikasi dan bisnis/layanan yang disediakannya.
Untuk memastikan alur kerja aplikasi yang sukses dan kelangsungan bisnis, Anda perlu menerapkan kebijakan pencadangan dan pemulihan yang sesuai dengan pencadangan harian, mingguan, bulanan, dan tahunan. Pencadangan tersebut akan berjalan pada periode kritis, seperti:
- sebelum jendela batch harian;
- sebelum penyerapan data besar-besaran;
- sebelum peningkatan versi aplikasi apa pun;
- pencadangan mingguan, bulanan, dan tahunan untuk memenuhi persyaratan peraturan;
- atau pemeliharaan terjadwal harian/mingguan lainnya.
Alat pencadangan
MySQL dan MariaDB menawarkan beberapa cara untuk menyiapkan dan menjalankan rencana pencadangan dan pemulihan. Metode ini mencakup pencadangan fisik dengan alat pencadangan mysql Enterprise MySQL , alat mariabackup MariaDB , atau Alat XtraBackup Percona . Selain itu, pencadangan logis dibuat dengan alat mysqldump MySQL mungkin berguna. Pilihan lain adalah pemulihan point-in-time dengan database bin-log (log transaksi) yang dikombinasikan dengan alat yang disebutkan sebelumnya.
Anda dapat mengasimilasi metode yang sesuai ke dalam strategi pencadangan untuk memaksimalkan pemulihan basis data jika terjadi kegagalan atau bencana.
Catatan:Di MariaDB versi 10.4.6, symlink mysqldump disebut mariadb-dump . Di versi yang lebih baru, termasuk 10.5.2, namanya berubah lagi – mysqldump menjadi symlink .
Untuk mengilustrasikan prosedurnya, saya akan menggunakan alat mariabackup untuk membuat cadangan fisik. Fungsi dasar alat ini sama dengan alat yang disebutkan di atas, meskipun ada beberapa perbedaan kecil yang unik untuk setiap alat.
Cadangan Basis Data Fisik
Pencadangan fisik adalah pencadangan tingkat file yang memberi Anda metode penyalinan file cepat. Pencadangan semacam itu lebih disukai dalam skenario pemulihan bencana, mengkloning database, dan/atau membuat database budak.
Saat membuat cadangan fisik, Anda dapat memilih untuk membuat cadangan penuh atau tambahan. Cadangan penuh mencakup pencadangan lengkap dari server basis data. Pencadangan tambahan menyimpan perubahan dari cadangan penuh atau tambahan terakhir saja.
Penting:Ukuran database mengatur waktu pencadangan. Oleh karena itu, strategi yang baik untuk mencadangkan basis data yang sangat besar adalah dengan menggabungkan pencadangan penuh dan tambahan. Dengan cara ini, Anda menghemat ruang penyimpanan cadangan serta total waktu pencadangan dan pemulihan.
Momen lain yang harus Anda perhatikan adalah saat memulihkan data dari cadangan fisik, Anda harus menghentikan proses instans database MySQL/MariaDB hingga langkah pemulihan terakhir selesai.
Anda dapat melakukan eksekusi pencadangan fisik lengkap sederhana sebagai berikut:
mariabackup --backup \
--target-dir=/data/backups/mariadb/D20210220 \
--user=backupuser --password=backuppasswd
–target-dir option memberi tahu alat pencadangan tempat menyimpan cadangan.
Dalam contoh ini, saya telah mengatur cadangan saya ke dalam direktori bernama DYYYYMMDD di mana setiap cadangan lengkap disimpan (D singkatan dari Harian). Dalam melakukannya, kami memiliki tindakan yang mudah untuk memulihkan database dari cadangan yang diambil pada tanggal tertentu.
Contoh berikutnya mendemonstrasikan menjalankan pencadangan tambahan sederhana:
mariabackup --backup \
--target-dir=/data/backups/mariadb/D20210220_inc1/ \
--incremental-basedir=/data/backups/mariadb/D20210220/ \
--user=backupuser --password=backuppasswd
Pencadangan tambahan berikutnya akan terlihat seperti ini:
mariabackup --backup \
--target-dir=/data/backups/mariadb/D20210220_inc2/ \
--incremental-basedir=/data/backups/mariadb/D20210220_inc1 \
--user=backupuser --password=backuppasswd
–berbasis tambahan opsi menginstruksikan alat pencadangan untuk menggunakan cadangan penuh atau tambahan yang diambil sebelumnya sebagai titik awal dalam membangun file delta tambahan untuk cadangan saat ini. Dengan cara ini, ia membangun rantai satu cadangan penuh dengan cadangan tambahan berikutnya. Bersama-sama, mereka membentuk satu cadangan tunggal untuk dipulihkan saat dibutuhkan.
Sekarang, mari kita cari tahu apa nama file database fisik tempat semua data direktori disimpan. Basis data yang terletak di pengontrol domain adalah direktori aktif. Direktori ini digunakan untuk mengelola pengguna, data, dll. Inti dari Active Directory adalah file database NTDS.DIT yang terdiri dari link, deskriptor keamanan, dan tabel data. Semua data direktori disimpan dalam file database fisik ini.
Penting untuk membedakan antara file fisik dan logis. Data sistem yang sebenarnya terletak di file fisik, sedangkan file logis berisi deskripsi catatan yang disimpan dalam file fisik.
Tugas memulihkan database MySQL dari file fisik terkadang sulit. mysqldump perintah mungkin membantu dalam kasus ini. Kami akan membahas topik ini lebih lanjut.
Cadangan Basis Data Logis
Cadangan logis dibuat dengan mysqldump alat. Metode pencadangan ini lebih fleksibel daripada pencadangan fisik. Ini terdiri dari semua pernyataan DML dan/atau DDL SQL yang diperlukan untuk membentuk cadangan yang konsisten, menggabungkan semua data yang dikomit dan perubahan yang dibuat sebelum dan selama pencadangan. Jika Anda ingin mengetahui lebih lanjut tentang cara membuat cadangan dan memulihkan semua basis data, Anda dapat membaca artikel ini.
Cadangan logis dapat berupa satu file atau beberapa file (dibuat dengan skrip tertentu). Selanjutnya, Anda dapat memulihkan struktur dan/atau data tanpa mematikan instans (proses) MySQL/MariaDB Anda. Oleh karena itu, pencadangan logis dilakukan pada tingkat database dan/atau tabel, sedangkan pencadangan fisik dilakukan pada tingkat sistem file (direktori dan file).
Perhatikan juga bahwa pencadangan logis secara eksklusif merupakan gambar pencadangan penuh dari database dan/atau tabel yang dimaksud.
Membuat cadangan logis dari seluruh instance MySQL/MariaDB di bawah ini:
mysqldump --all-databases --single-transaction \
--quick --lock-tables=false \
-u backupuser -p backuppasswd \
> /data/backups/mariadb/logical/D20210220/full-backup-$(date +'%Y%m%d_%H%M%S').sql
Perhatikan bahwa pencadangan fisik dan pencadangan logis secara khusus dibedakan dalam sistem file untuk tujuan pengelolaan pencadangan.
Tidak seperti contoh sebelumnya, cadangan logis dari satu database (skema) dibuat dengan cara berikut:
mysqldump empdb --single-transaction \
--quick --lock-tables=false \
-u backupuser -p backuppasswd \
> /data/backups/mariadb/logical/D20210220/empdb-full-backup-$(date +'%Y%m%d_%H%M%S').sql
Terakhir, untuk membuat cadangan logis dari satu tabel dalam database, tambahkan nama tabel setelah database:
mysqldump empdb departments --single-transaction \
--quick --lock-tables=false \
-u backupuser -p backuppasswd \
> /data/backups/mariadb/logical/D20210220/empdb-departments-full-backup-$(date +'%Y%m%d_%H%M%S').sql
Saat Anda perlu mengedit dan menambahkan pernyataan DROP DATABASE atau DROP TABLE ke skenario pemulihan, bekerja dengan file cadangan besar mungkin memiliki efek menyempitkan editor teks hingga membuat mereka tersedak.
Dalam kasus seperti itu, pertimbangkan untuk menambahkan opsi lain, seperti –add-drop-database dan/atau –add-drop-table untuk memasukkan pernyataan DROP ini ke dalam cadangan. Dalam skenario lain, Anda mungkin ingin mengecualikan pernyataan ini dan menggantinya dengan –skip-add-drop-table opsi untuk perintah.
Namun, Anda juga dapat membuat cadangan hanya data atau DDL saja menggunakan –no-create-info atau –tidak ada data pilihan. Pencadangan data dan struktur yang terpisah dapat menjadi pilihan yang baik dalam beberapa skenario pemulihan, terutama bila Anda hanya memerlukan struktur DDL untuk membuat database kloning kosong dan/atau tabelnya.
Mencadangkan Basis Data Menggunakan Cuplikan Disk
Seiring bertambahnya data, mungkin perlu untuk mengaturnya di beberapa disk dan/atau sistem file. Selain alasan kinerja, karena I/O didistribusikan di beberapa disk/sistem file, Anda harus memastikan bahwa strategi pencadangan dan pemulihan yang efisien mencakup kemampuan snapshot disk dan sistem file.
Mulailah dengan merancang dan membangun tata letak sistem file tempat setiap database, grup tabel, dan indeks berada. Kemudian, atur tabel Anda dan konfigurasikan sistem database. Mereka harus berada dalam satu direktori:
innodb_home_dir = /<path where your InnoDB tables will reside>Atau, Anda dapat menggunakan DATA_DIRECTORY dan INDEX_DIRECTORY opsi di BUAT pernyataan tabel untuk mendistribusikannya secara terpisah ke lokasi sistem file yang berbeda.
Untuk InnoDB, pastikan untuk menggunakan file_per_table =ON (default AKTIF di versi terbaru). Pilih jalur untuk tabel InnoDB dengan hati-hati saat Anda membuatnya. Tidak mungkin mengubah jalur tanpa menjatuhkan dan membuat ulang tabel.
Sangat membantu untuk memiliki sistem file yang tepat dengan kemampuan snapshot bawaan, mis. XFS dan ZFS di Linux. Perhatikan bahwa membuat cadangan snapshot mirip dengan membuat cadangan fisik, tetapi memiliki kekhususan. Ini membutuhkan penghentian proses penulisan (FLUSH dengan READ LOCK atau serupa — lihat TAHAP CADANGAN perintah dalam dokumentasi online MariaDB) sebelum mengambil snapshot dan melepaskan LOCKS segera setelah snapshot selesai. Hal ini diperlukan untuk memastikan konsistensi data.
Anda harus mempertimbangkan dan menggunakan cadangan snapshot dalam skenario pemulihan bencana. Namun, mereka juga cocok untuk mengkloning instance database.
Strategi Pemulihan
Pemulihan dari Cadangan Fisik
Sebelumnya, kami telah menjelaskan langkah-langkah pencadangan fisik. Dengan cara ini, Anda dapat membuat rantai cadangan lengkap atau rantai cadangan penuh dan tambahan. Opsi terakhir berarti bahwa full backup diikuti dengan incremental backup berikutnya adalah titik nol jika terjadi kegagalan.
Misalnya, DBA mengambil pencadangan penuh pada hari Minggu dan pencadangan tambahan pada hari lain. Kegagalan terjadi setelah membuat cadangan tambahan pada hari Rabu. Oleh karena itu, mereka perlu memulihkan database. Dalam keadaan seperti itu, DBA kami harus menggunakan cadangan lengkap yang dibuat pada hari Minggu dan cadangan tambahan yang dibuat pada hari Senin, Selasa, dan Rabu. Jika ada cadangan penuh setiap hari, itu akan cukup untuk memulihkan cadangan hari Rabu.
Untuk memulihkan cadangan "terdekat" setelah gagal, baik itu cadangan penuh atau tambahan, Anda harus memastikan bahwa SEMUA file cadangan konsisten pada waktunya dengan waktu penyelesaian pencadangan terdekat. Jika tidak, mesin InnoDB akan menolak data dengan menganggapnya rusak.
Poin penting lainnya adalah, saat Anda menyiapkan cadangan, salin cadangan lengkap yang terlibat ke lokasi lain sebelum menerapkan langkah-langkah untuk memastikan konsistensi point-in-time. Dengan cara ini, Anda mempertahankan status cadangan asli, yang mungkin berguna nanti. Saya sangat menyarankan untuk tetap berpegang pada pendekatan ini.
Untuk menyiapkan cadangan lengkap, pilih yang terdekat dengan kegagalan, salin ke lokasi yang diinginkan, dan jalankan perintah berikut:
mariabackup --prepare \
--target-dir=data/backups/mariadb/COPY_D20210220
Untuk memulihkan ke cadangan tambahan terdekat, siapkan salinan cadangan lengkap terdekat dan tambahkan semua cadangan tambahan yang relevan dalam urutan berikutnya . Gambar database yang dipulihkan harus sebagai berikut:
Kami mencapai ini dengan menjalankan persiapan perintah untuk setiap pencadangan tambahan seperti yang ditunjukkan di bawah ini:
mariabackup --prepare \
--target-dir=/data/backups/mariadb/COPY_D20210220 \
--incremental-dir=/data/backups/mariadb/D20210220_INC#
Setelah menyiapkan salinan cadangan, kita harus mematikan instance database (proses). Selain itu, kita harus mengosongkan direktori basis data sebelum menyelesaikan proses pemulihan. Anda dapat mengeluarkan perintah dengan –copy-back pilihan
mariabackup --copy-back \
--target-dir=data/backups/mariadb/COPY_D20210220
atau dengan –mundurkan pilihan:
mariabackup --move-back \
--target-dir=data/backups/mariadb/COPY_D20210220
Perintah terakhir memindahkan direktori yang disalin ke direktori database. Menyalin cadangan asli ke lokasi lain adalah pilihan yang bijaksana. Jika tidak, cadangan akan hilang, karena tidak dapat digunakan untuk situasi dan skenario lain.
Langkah terakhir sebelum memulai instance database adalah menyesuaikan kepemilikan file agar sesuai dengan pengguna dan grup pemilik proses. Biasanya, ini adalah MySQL.
Pemulihan dari pencadangan logis
Cukup sering, kita mengabaikan satu poin penting saat memulihkan database dan/atau tabel menggunakan pencadangan logis. Poin ini adalah menyetel max_allowed_packet ukuran sesi (mungkin lebih bijaksana untuk mengaturnya secara global) ke nilai maksimum 1073741824. Penting untuk memastikan bahwa buffer besar dan pernyataan INSERT masuk ke dalam satu paket antara klien dan server. Ini akan mengurangi waktu pemulihan.
Aspek kunci lainnya saat membuat cadangan adalah menyertakan atau mengecualikan pernyataan DROP seperti yang disebutkan sebelumnya. Kami membutuhkannya untuk memastikan menjalankan proses pemulihan cadangan semulus mungkin. Dengan mengingat hal itu, gunakan kode di bawah ini untuk menjalankan pemulihan cadangan:
mysql -u backupuser -p backuppasswd < /data/backups/mariadb/logical/D20210220/emp-full-backup-20210228_153726.sqlJika Anda tidak memiliki basis data apa pun yang disertakan dalam pencadangan, seperti cadangan basis data individual, atau Anda perlu mengarahkan pemulihan ke basis data lain, gunakan kode yang berbeda:
mysql -u backupuser -p backuppasswd newemp < /data/backups/mariadb/logical/D20210220/emp-full-backup-20210228_153726.sqlPemulihan dengan cuplikan disk
Untuk memulihkan dari cuplikan disk selalu mulai dengan memastikan bahwa sistem basis data dimatikan sebelum proses pemulihan dijalankan . Setiap upaya untuk memulihkan database langsung menggunakan snapshot disk akan mengakibatkan inkonsistensi data dan, kemungkinan besar, kerusakan data.
Pemulihan tepat waktu
Point in time recovery (PITR), seperti namanya, adalah metode untuk memulihkan database dan tabel sedekat mungkin dengan waktu sebelum kegagalan. Atau, jika proses batch harian gagal dan perlu dijalankan kembali, Anda juga memiliki satu-satunya pilihan – lakukan pemulihan cadangan PITR.
Sangat penting untuk mengaktifkan database bin-log dan mengatur format bin-log ke logging Berbasis Pernyataan, Berbasis Baris, atau Campuran, tergantung pada jenis beban kerja yang dijalankan database Anda. Selanjutnya, Anda mungkin perlu mengaktifkan kompresi menggunakan log_bin_compress =ON (default OFF) untuk menghemat ruang disk.
Karena bin-log adalah log transaksi dan dibuat secara berurutan, sangat penting untuk membuat cadangan semua file log. Adapun proses PITR, tidak mungkin tanpa file log. Selain itu, pemeliharaan bin-log dan siklus hidup harus mengikuti siklus hidup cadangan penuh dan tambahan. Jadi, pastikan untuk hanya menghapus log yang lebih lama dari cadangan terlama dalam kebijakan pencadangan.
Anda dapat membersihkan log biner dengan dua cara. Pertama, dengan mendeklarasikan nama bin-log terdekat ke backup tertua seperti yang ditunjukkan pada perintah purge di bawah ini:
PURGE BINARY LOGS TO 'mariadb-bin.000063';Kedua, dengan mendeklarasikan tanggal backup terlama yang disimpan dalam perintah purge:
PURGE BINARY LOGS BEFORE '2021-01-20 00:00:00';Untuk mempersiapkan pemulihan, kita perlu mengambil semua pernyataan yang diperlukan untuk diputar ulang ke titik waktu yang diperlukan. Kumpulkan semua bin-log yang tersedia sejak pencadangan dimulai hingga saat Anda memulihkannya.
Mulailah dengan memeriksa daftar log sejak pencadangan berakhir hingga waktu PITR:
mysqlbinlog --start-datetime=<backup end datetime> --stop-datetime=<PITR datetime> \
<list of binlogs> \
> temporary_file.sql
Kemudian, periksa file-file sementara untuk menemukan posisi log yang tepat yang ingin Anda terapkan dan gunakan. Ini adalah –posisi awal dan –posisi berhenti yang mengatur posisi yang tepat dalam perintah dan menjalankan kembali mysqlbinlog perintah:
mysqlbinlog --start-position=<exact log start position> --stop-position=<exact log position to stop on> \
<list of binlogs> \
> final_temporary_PITR_file.sql
Pada titik ini, proses pemulihan telah dimulai. Ini menggunakan cadangan fisik atau logis, penuh atau tambahan.
Selesaikan pemulihan dengan menerapkan final_temporary_PITR_file.sql menggunakan klien MySQL seperti yang ditunjukkan di bawah ini:
mysql -u backupuser -p backuppasswd < final_temporary_PTR_file.sqlKami telah menyelesaikan pemulihan PITR dengan memulihkan cadangan dan memutar ulang transaksi dari log ke titik terdekat dengan saat terjadinya kegagalan.
Meja kerja
Untuk desain dan pengembangan database, pengujian dan pemeliharaan di MySQL dan MariaDB, kita dapat menggunakan aplikasi Windows Workbench. Ia bekerja di Linux, juga. Dengan aplikasi ini, pengguna dapat mendesain database, melihat dan mengubah meta data, mentransfer data dan meta data, dan banyak lagi. Perlu ditambahkan bahwa mungkin untuk menggunakan dbForge Studio untuk MySQL daripada Workbench.
Kesimpulan
Secara keseluruhan, kami telah membahas dan mengilustrasikan secara singkat teknik pencadangan dan pemulihan basis data dengan alat dan metode yang tersedia di MySQL dan MariaDB.
Untuk memulihkan sistem database dari kegagalan apa pun dengan sukses, kita harus menerapkan pencadangan fisik dan logis metode yang disebutkan di atas ke dalam kebijakan dan rencana, dari keseluruhan sistem hingga tabel individual.
Untuk melakukan PITR dengan sukses, kita memerlukan bin-log diaktifkan dan kebutuhan pengelolaan log yang tepat di tempat.
Namun, hanya menggunakan satu metode pencadangan dan bin-log yang hilang akan menjadi pendekatan yang salah. Hal ini dapat mengakibatkan hilangnya data dan membahayakan kelangsungan bisnis aplikasi Anda. Jadi, gabungkan metode yang berbeda dan selalu sertakan file log ke dalam kebijakan pencadangan dan pemulihan!
