Panduan untuk membuat cadangan database

“Oh, tidak ada tempat berlindung yang bisa menahan hantaman meteor. Tetapi Anda, seperti semua orang, memiliki cadangan, jadi jangan khawatir.



Stanislav Lem, "The Star Diaries of Iyon the Tikhoi"

Mencadangkan mengacu pada menyimpan salinan data Anda di suatu tempat di luar lokasi penyimpanan utama.







Tujuan utama pencadangan adalah untuk memulihkan data setelah hilang. Dalam hal ini, kami sering mendengar bahwa jika Anda memiliki replika database, Anda selalu dapat memulihkan data darinya, dan Anda tidak memerlukan cadangan. Faktanya, pencadangan memungkinkan Anda menyelesaikan setidaknya tiga tugas yang tidak dapat diselesaikan menggunakan replika, dan Anda tidak dapat menginisialisasi replika tanpa cadangan.



Pertama, cadangan memungkinkan Anda memulihkan data setelah kesalahan logis. Misalnya, seorang akuntan menghapus grup transaksi, atau DBA menghancurkan tablespace. Kedua operasi tersebut benar-benar sah dari sudut pandang database, dan proses replikasi akan mereproduksinya dalam database replika.



Kedua, DBMS modern adalah sistem perangkat lunak yang sangat andal, tetapi kadang-kadang terjadi kerusakan pada struktur internal database, setelah itu akses ke data hilang. Apa yang sangat menyinggung, pelanggaran semacam itu biasanya terjadi pada beban tinggi atau saat memasang semacam pembaruan. Tetapi baik beban tinggi maupun pembaruan rutin menunjukkan bahwa database bukanlah database uji, dan data yang disimpan di dalamnya sangat berharga.



Terakhir, tugas ketiga, yang solusinya memerlukan salinan cadangan, adalah mengkloning database, misalnya, untuk tujuan pengujian.



Pencadangan database entah bagaimana didasarkan pada salah satu dari dua prinsip:

• Mengambil data dengan penyimpanan berikutnya dalam format arbitrer;
• Snapshot dari file database dan menyimpan log.

Mari kita lihat lebih dekat prinsip-prinsip ini dan alat yang menerapkannya.

Mengupload data

Set utilitas yang disertakan dengan DBMS harus memiliki alat untuk mengunggah dan mengunduh data. Data disimpan baik dalam format teks atau dalam format biner khusus untuk DBMS tertentu. Tabel di bawah mencantumkan alat-alat tersebut:





Format teks bagus karena dapat diedit atau bahkan dibuat oleh program eksternal, dan format biner, pada gilirannya, bagus karena memungkinkan Anda untuk dengan cepat membongkar dan memuat data karena pemuatan paralel dan penghematan sumber daya pada konversi format.



Terlepas dari kesederhanaan dan kejelasan gagasan untuk mengunduh data, metode ini jarang digunakan untuk mencadangkan basis industri yang dimuat. Berikut alasan mengapa pembongkaran tidak cocok untuk pencadangan penuh:

• proses pembongkaran menciptakan beban yang signifikan pada sistem sumber;
• pembongkaran membutuhkan banyak waktu - pada saat pembongkaran selesai, itu akan menjadi tidak relevan;
• hampir tidak mungkin untuk membuat pembongkaran yang konsisten dari seluruh database di bawah beban tinggi, karena DBMS dipaksa untuk menyimpan snapshot dari statusnya pada saat pembongkaran dimulai. Semakin banyak transaksi telah dilakukan sejak awal pengunggahan, semakin besar volume snapshot (salinan data yang tidak relevan di PostgreSQL, batalkan ruang di Oracle, tempdb di Microsoft SQL Server, dll.);
• pembongkaran mempertahankan struktur logis data, tetapi tidak mempertahankan struktur fisiknya - parameter penyimpanan fisik tabel, indeks, dll.; membangun kembali indeks pada saat boot bisa memakan waktu lama.

Meski demikian, bongkar muat memiliki keuntungan:

• selektivitas tinggi: Anda dapat membongkar tabel individual, bidang individual, dan bahkan baris individual;
• data yang diupload dapat dimuat ke database versi lain, dan jika upload dibuat dalam format teks, maka ke database lain.

Jadi, pembongkaran terutama digunakan untuk tugas-tugas seperti mencadangkan tabel kecil (misalnya, direktori) atau mendistribusikan set data dengan rilis aplikasi berikutnya.



Metode paling umum untuk mencadangkan database adalah menyalin file database.

Penyimpanan "Dingin" dari file database

Ide yang jelas adalah menghentikan database dan menyalin semua file-nya. Ini disebut cadangan dingin. Metode ini sangat andal dan sederhana, tetapi memiliki dua kelemahan yang jelas:

• dari cadangan dingin, Anda hanya dapat memulihkan status basis data saat mematikan; transaksi yang dilakukan setelah database dimulai ulang tidak akan disertakan dalam cadangan "dingin";
• tidak setiap database memiliki jendela teknologi ketika database dapat dihentikan.

Jika Anda senang dengan backup dingin, ingatlah itu

• «» . , «» , . , Oracle online redo, , , . PostgreSQL , , .
• , . , «» .

«»

Kebanyakan backup database modern dilakukan dengan menyalin file database tanpa menghentikan database. Beberapa masalah terlihat di sini:

• Pada awal penyalinan, konten database mungkin tidak sama dengan konten file, karena beberapa informasi ada di cache dan belum ditulis ke disk.
• Selama penyalinan, konten database dapat berubah. Jika struktur data yang dapat diubah digunakan, konten file berubah, dan ketika struktur yang tidak dapat diubah digunakan, kumpulan file berubah: file baru muncul dan yang lama dihapus.
• Karena menulis data ke database dan membaca file database tidak disinkronkan dengan cara apa pun, program cadangan mungkin membaca halaman yang salah, di mana setengahnya dari halaman versi lama dan separuh lainnya dari yang baru.

Agar pencadangan konsisten, setiap DBMS memiliki perintah yang menginformasikan bahwa proses pencadangan telah dimulai. Secara sintaksis, perintah ini mungkin terlihat berbeda:

• di Oracle itu adalah perintah terpisah ALTER DATABASE / TABLESPACE BEGIN BACKUP;
• di PostgreSQL, fungsi pg_start_backup ();
• di Microsoft SQL Server dan DB2, persiapan untuk cadangan tersirat selama perintah BACKUP DATABASE;
• di MySQL Enterprise, Percoba Server, Cassandra, dan MongoDB, persiapan secara implisit dilakukan oleh utilitas eksternal - mysqlbackup, Percona XtraBackup, OpsCenter, dan Ops Manager.

Terlepas dari perbedaan sintaksis, proses mempersiapkan cadangan terlihat sama.



Seperti inilah tampilan persiapan untuk backup di DBMS dengan struktur disk variabel, yaitu di semua sistem relasional disk tradisional:

1. Momen awal pencadangan akan diingat; backup harus berisi log database mulai sekarang.
2. Sebuah pos pemeriksaan dilakukan, yaitu, semua perubahan yang terjadi di halaman data hingga titik waktu akan dibuang ke disk. Ini memastikan bahwa tidak ada log yang diperlukan sebelum memulai pencadangan selama pemulihan.
3. : , , , . , . , . , , .
4. , , . , , .

Setelah semua prosedur di atas selesai, Anda dapat menyalin file data menggunakan alat sistem operasi - cp, rsync, dan lainnya. Mengaktifkan mode cadangan mengurangi kinerja database: pertama, volume log meningkat, dan kedua, jika tiba-tiba terjadi kegagalan dalam mode cadangan, pemulihan akan memakan waktu lebih lama, karena header file data tidak diperbarui. Semakin cepat pencadangan selesai, semakin baik untuk database, sehingga sesuai untuk menggunakan alat seperti snapshot sistem file atau mirror break (BCV) dalam larik disk. Beberapa DBMS (Oracle, PostgreSQL) memberikan kesempatan kepada administrator untuk secara mandiri memilih metode penyalinan,lainnya (Microsoft SQL Server) menyediakan antarmuka untuk mengintegrasikan utilitas pencadangan asli dengan sistem file atau mesin penyimpanan.



Di akhir pencadangan, Anda perlu mengembalikan database ke kondisi normalnya. Di Oracle, ini dilakukan dengan perintah ALTER DATABASE / TABLESPACE END BACKUP, di PostgreSQL, dengan memanggil fungsi pg_stop_backup (), dan di database lain, dengan rutinitas internal dari perintah terkait atau layanan eksternal.



Seperti inilah garis waktu untuk proses pencadangan:

• Persiapan untuk pencadangan (memulai pencadangan) membutuhkan waktu, terkadang cukup lama. Bahkan jika volume cermin atau sistem file snapshot digunakan, proses pencadangan tidak akan terjadi secara instan.
• Bersama dengan file data, log perlu disimpan sejak persiapan untuk pencadangan dimulai dan diakhiri dengan saat database kembali ke keadaan normal.
• Anda dapat memulihkan dari cadangan ini pada saat database kembali ke keadaan normalnya . Pemulihan ke momen sebelumnya tidak dimungkinkan.

Dengan database yang menggunakan struktur data yang tidak dapat diubah (snapshot, pohon LSM), situasinya menjadi lebih mudah. Persiapan pencadangan terdiri dari langkah-langkah berikut:

1. Data dari memori dipindahkan ke disk.
2. Daftar file yang termasuk dalam cadangan dicatat. Sampai proses pencadangan selesai, database dilarang menghapus file-file ini, meskipun tidak lagi diperlukan.

Saat ada sinyal tentang akhir pencadangan, database dengan struktur yang tidak dapat diubah dapat kembali menghapus file yang tidak diperlukan.

Pemulihan titik

Cadangan memungkinkan Anda memulihkan status database ke saat perintah untuk kembali dari mode cadangan selesai. Namun, bencana yang membutuhkan pemulihan bisa terjadi kapan saja. Tugas memulihkan status database ke momen arbitrer disebut "pemulihan titik waktu".



Untuk melakukan ini, Anda harus menyimpan log basis data sejak pencadangan selesai, dan terus menerapkan log ke salinan yang dipulihkan selama proses pemulihan. Setelah database dipulihkan dari salinan cadangan di akhir salinan, status database (file dan halaman cache) dijamin benar, sehingga mode logging khusus tidak diperlukan. Dengan menerapkan log hingga saat yang diinginkan, Anda bisa mendapatkan status database kapan saja.



Jika kecepatan pemulihan cadangan dibatasi hanya oleh bandwidth disk, maka kecepatan penerapan log biasanya dibatasi oleh kinerja prosesor. Jika perubahan terjadi di database utama secara paralel, maka selama pemulihan semua perubahan dilakukan secara berurutan - dalam urutan pembacaannya dari log. Oleh karena itu, waktu pemulihan secara linier bergantung pada seberapa jauh titik pemulihan dari titik akhir pencadangan. Oleh karena itu, Anda harus membuat backup penuh cukup sering - setidaknya sekali seminggu untuk database dengan beban transaksional rendah dan sebelum menyalin harian dari database yang sangat dimuat.

Cadangan tambahan

Untuk mempercepat pemulihan point-to-point, saya ingin dapat mencadangkan sesering mungkin, tetapi pada saat yang sama tidak menggunakan ruang disk ekstra dan tidak membebani database dengan tugas pencadangan.



Solusi untuk masalah ini adalah incremental backup, yaitu hanya menyalin halaman data yang telah diubah sejak backup sebelumnya.

Cadangan tambahan hanya masuk akal untuk DBMS yang menggunakan struktur data yang dapat berubah.



Kenaikan dapat dihitung baik dari cadangan penuh (salinan kumulatif) dan dari salinan sebelumnya (salinan diferensial).







Sayangnya, tidak ada terminologi yang seragam, dan pabrikan yang berbeda menggunakan istilah yang berbeda:





Dengan incremental backup, proses pemulihan point-to-point terlihat seperti ini:

• cadangan penuh terakhir yang dibuat sebelum pemulihan dipulihkan;
• salinan inkremental dikembalikan ke salinan lengkap;
• menggulung log dari titik awal pencadangan hingga titik pemulihan.

Memiliki salinan kumulatif mempercepat proses pemulihan. Jadi, misalnya, untuk memulihkan status dasar ke titik antara T3 dan T4, perlu memulihkan dua salinan tambahan, dan mengembalikan ke titik setelah T4 - hanya satu.

Jelas, volume satu salinan kumulatif kurang dari volume beberapa salinan diferensial, karena beberapa halaman telah berubah beberapa kali, dan setiap salinan tambahan berisi versi halamannya sendiri.



Ada tiga cara untuk membuat salinan inkremental:

1. membuat salinan lengkap dan menghitung perbedaan dari salinan lengkap sebelumnya;
2. parsing log, membuat daftar halaman yang diubah dan halaman cadangan yang termasuk dalam daftar;
3. permintaan untuk halaman yang diubah dalam database.

Metode pertama menghemat ruang disk, tetapi tidak menyelesaikan masalah pengurangan beban pada database. Selain itu, jika kita memiliki full backup, maka mengubahnya menjadi incremental backup tidak ada gunanya, karena memulihkan backup penuh lebih cepat daripada memulihkan salinan lengkap sebelumnya dan increment. Dengan pendekatan ini, lebih baik mengalihkan tugas menghemat ruang disk ke komponen khusus dengan mekanisme deduplikasi bawaan. Ini dapat berupa sistem penyimpanan khusus (EMC DataDomain, HPE StorageWorks VLS, seluruh lini NetApp), atau produk perangkat lunak (ZFS, Veritas NetBackup PureFile, Deduplikasi Data Server Windows).



Metode kedua dan ketiga berbeda dalam mekanisme untuk menentukan daftar halaman yang diubah. Parsing log lebih intensif sumber daya, ditambah lagi Anda perlu mengetahui struktur file log untuk menerapkannya. Paling mudah untuk menanyakan database itu sendiri halaman mana yang telah berubah, tetapi untuk ini kernel DBMS harus memiliki fungsionalitas untuk melacak blok yang diubah (pelacakan perubahan blok).



Fungsionalitas incremental backup pertama kali diperkenalkan dengan perangkat lunak Oracle Recovery Manager (RMAN), yang diperkenalkan dengan rilis Oracle 8i. Oracle segera menerapkan pelacakan blok yang diubah, jadi tidak perlu mengurai log.



PostgreSQL tidak melacak blok yang diubah, jadi utilitas pg_probackup, yang dikembangkan oleh perusahaan Rusia Postgres Professional, mendeteksi halaman yang diubah dengan menganalisis log. Namun, perusahaan juga memasok PostgresPro, yang menyertakan ekstensi ptrack yang melacak perubahan halaman. Saat menggunakan pg_probackup dengan PostgresPro, utilitas menanyakan database itu sendiri untuk halaman yang dimodifikasi, seperti yang dilakukan RMAN.



Microsoft SQL Server, seperti Oracle, melacak halaman yang diubah, tetapi perintah BACKUP hanya memungkinkan pencadangan penuh dan kumulatif.



DB2 memiliki kemampuan untuk melacak halaman yang diubah, tetapi secara default dinonaktifkan. Setelah diaktifkan, DB2 akan memungkinkan pencadangan penuh, diferensial, dan kumulatif.



Perbedaan penting antara alat yang dijelaskan di bagian ini (kecuali untuk pg_probackup) dan alat pencadangan berbasis file adalah alat tersebut meminta gambar halaman ke database daripada membaca data dari disk itu sendiri. Kerugian dari pendekatan ini adalah beban tambahan kecil di pangkalan. Namun, kelemahan ini lebih dari dikompensasi oleh fakta bahwa pembacaan halaman selalu benar, jadi tidak perlu mengaktifkan mode penjurnalan khusus selama pencadangan.



Perhatikan sekali lagi bahwa adanya incremental backup tidak menggantikan persyaratan log untuk dipulihkan ke titik waktu tertentu. Oleh karena itu, dalam database industri, log terus ditulis ulang ke media eksternal, dan backup, penuh dan / atau inkremental, dibuat sesuai jadwal.



Implementasi terbaik dari ide incremental backup saat ini adalah Zero Data Loss Recovery Appliance (sistem yang direkayasa dalam terminologi Oracle) - solusi Oracle khusus untuk mencadangkan database-nya sendiri. Kompleks ini adalah sekumpulan server dengan volume disk yang besar, di mana versi modifikasi perangkat lunak Recovery Manager diinstal dan dapat bekerja dengan perangkat lunak Oracle dan kompleks perangkat keras lainnya (Peralatan Basis Data, Exadata, SPARC Supercluster), dan dengan basis data Oracle pada infrastruktur tradisional. Tidak seperti RMAN “biasa”, ZDLRA menerapkan konsep “incremental forever”. Sistem membuat salinan lengkap database hanya sekali, dan kemudian hanya membuat salinan tambahan. Modul RMAN tambahan memungkinkan Anda untuk menggabungkan salinan,membuat salinan lengkap baru dari yang inkremental.



Sebagai penghargaan dari pengembang Rusia, perlu dicatat bahwa pg_probackup juga dapat menggabungkan salinan tambahan.







Tidak seperti banyak pertanyaan serupa, pertanyaan "metode pencadangan mana yang lebih baik" memiliki jawaban yang jelas - yang terbaik adalah utilitas asli untuk DBMS bekas yang menyediakan kemampuan untuk pencadangan tambahan.



Untuk DBA, masalah pemilihan strategi backup dan integrasi backup database ke dalam infrastruktur perusahaan jauh lebih penting. Tetapi pertanyaan-pertanyaan ini berada di luar cakupan artikel ini.