MariaDB
 sql >> Teknologi Basis Data >  >> RDS >> MariaDB

ClusterControl 1.5 - Verifikasi Cadangan Otomatis, Bangun Budak Dari Cadangan, dan Integrasi Cloud

Inti dari ClusterControl adalah otomatisasinya, seperti memastikan bahwa data Anda dicadangkan dengan aman dan siap untuk dipulihkan kapan pun terjadi kesalahan. Memiliki strategi pencadangan dan rencana pemulihan bencana yang efektif adalah kunci keberhasilan aplikasi atau lingkungan apa pun.

Dalam rilis terbaru kami, ClusterControl 1.5, kami telah memperkenalkan sejumlah penyempurnaan untuk mencadangkan sistem berbasis MySQL dan MariaDB.

Salah satu peningkatan utama adalah kemampuan untuk mencadangkan dari ClusterControl ke penyedia cloud pilihan Anda. Penyedia cloud seperti Google Cloud Services dan Amazon S3 masing-masing menawarkan penyimpanan yang hampir tidak terbatas, sehingga mengurangi kebutuhan ruang lokal. Ini memungkinkan Anda menyimpan file cadangan lebih lama, selama yang Anda inginkan dan tidak mengkhawatirkan ruang disk lokal.

Mari jelajahi semua fitur pencadangan baru yang menarik untuk ClusterControl 1.5...

Desain Ulang Wizard Pencadangan/Pemulihan

Pertama-tama, Anda akan melihat wizard pencadangan dan pemulihan telah diubah untuk meningkatkan pengalaman pengguna dengan lebih baik. Sekarang akan dimuat sebagai menu samping di sebelah kanan layar:

Daftar cadangan juga mendapatkan sedikit perubahan di mana detail cadangan ditampilkan saat Anda mengklik cadangan tertentu:

Anda akan dapat melihat lokasi pencadangan dan basis data mana yang ada di dalam pencadangan. Ada juga opsi untuk memulihkan cadangan atau mengunggahnya ke awan.

Cadangan yang Kompatibel dengan PITR

ClusterControl melakukan pencadangan mysqldump standar dengan skema terpisah dan dump data. Ini membuatnya mudah untuk memulihkan sebagian cadangan. Namun, ini merusak konsistensi pencadangan (skema dan data dibuang dalam dua sesi terpisah), sehingga tidak dapat digunakan untuk menyediakan pemulihan slave atau point-in-time.

Cadangan yang kompatibel dengan PITR mysqldump berisi satu file dump tunggal, dengan info GTID, file binlog, dan posisi. Dengan demikian, hanya node basis data yang menghasilkan log biner yang akan memiliki opsi "kompatibel dengan PITR", seperti yang disorot pada tangkapan layar di bawah ini:

Ketika opsi yang kompatibel dengan PITR diaktifkan, bidang database dan tabel berwarna abu-abu karena ClusterControl akan selalu melakukan pencadangan terhadap semua database, peristiwa, pemicu, dan rutinitas server MySQL target.

Baris berikut akan muncul di ~50 baris pertama dari file dump yang telah selesai:

$ head -50 mysqldump_2017-11-07_072250_complete.sql
...
-- GTID state at the beginning of the backup
--
SET @@GLOBAL.GTID_PURGED='20dc5247-4a98-ee18-73af-5c79373388ee:1-1681';

--
-- Position to start replication or point-in-time recovery from
--
CHANGE MASTER TO MASTER_LOG_FILE='binlog.000001', MASTER_LOG_POS=2457790;
...

Informasi tersebut dapat digunakan untuk membuat slave dari cadangan, atau melakukan pemulihan point-in-time bersama-sama dengan log biner, di mana Anda dapat memulai pemulihan dari MASTER_LOG_FILE dan MASTER_LOG_POS yang dilaporkan dalam file dump menggunakan utilitas "mysqlbinlog". Perhatikan bahwa log biner tidak didukung oleh ClusterControl.

Build Slave from Backup Fitur lainnya adalah kemampuan untuk membuat slave langsung dari backup yang kompatibel dengan PITR, bukan dari master yang dipilih. Ini adalah keuntungan besar karena membongkar server master. Opsi ini dapat digunakan dengan Replikasi MySQL atau Galera Cluster. Cadangan yang ada dapat digunakan untuk membangun kembali slave replikasi yang ada atau menambahkan slave replikasi baru selama fase staging, seperti yang ditunjukkan pada tangkapan layar berikut:

Setelah pementasan selesai, budak akan terhubung ke master yang dipilih dan mulai mengejar. Sebelumnya, ClusterControl melakukan backup streaming langsung dari master yang dipilih menggunakan Percona Xtrabackup. Ini dapat memengaruhi kinerja master saat menskalakan kumpulan data besar, meskipun operasinya tidak memblokir master. Dengan opsi baru, jika cadangan disimpan di ClusterControl, hanya host ini (ClusterControl + slave) yang akan sibuk saat melakukan staging data pada slave.

Cadangkan ke Cloud

Cadangan sekarang dapat diunggah secara otomatis di cloud. Ini membutuhkan modul ClusterControl untuk diinstal, yang disebut clustercontrol-cloud (Modul integrasi cloud) dan clustercontrol-clud (Cloud download/upload CLI) yang tersedia di v1.5 dan yang lebih baru. Instruksi pemutakhiran telah disertakan dengan paket-paket ini dan mereka datang tanpa konfigurasi tambahan apa pun. Saat ini, platform cloud yang didukung adalah Amazon Web Services dan Google Cloud Platform. Kredensial cloud dikonfigurasi di bawah ClusterControl -> Pengaturan -> Integrasi -> Penyedia Cloud.

Saat membuat atau menjadwalkan pencadangan, Anda akan melihat opsi tambahan berikut saat "Unggah Cadangan ke awan" diaktifkan:

Fitur ini memungkinkan unggahan satu kali atau menjadwalkan pencadangan untuk diunggah setelah selesai (Amazon S3 atau Google Cloud Storage). Anda kemudian dapat mengunduh dan memulihkan cadangan sesuai kebutuhan.

Kompresi Kustom untuk mysqldump

Fitur ini sebenarnya pertama kali diperkenalkan dengan ClusterControl v1.4.2 setelah dirilis. Kami menambahkan tingkat kompresi cadangan berdasarkan gzip. Sebelumnya, ClusterControl menggunakan kompresi cadangan default (level 6) jika tujuan pencadangan berada di node pengontrol. Kompresi terendah (level 1 - tercepat, kompresi lebih sedikit) digunakan jika tujuan pencadangan berada di host database itu sendiri, untuk memastikan dampak minimal ke database selama operasi kompresi.

Dalam versi ini, kami telah menyempurnakan aspek kompresi dan kini Anda dapat menyesuaikan tingkat kompresi, terlepas dari tujuan pencadangan. Saat memutakhirkan instans ClusterControl Anda, semua pencadangan terjadwal akan secara otomatis dikonversi untuk menggunakan level 6, kecuali jika Anda mengeditnya secara eksplisit di v1.5.

Kompresi cadangan sangat penting ketika kumpulan data Anda besar, dikombinasikan dengan kebijakan penyimpanan cadangan yang lama, sementara ruang penyimpanan terbatas. Mysqldump, yang berbasis teks, dapat memanfaatkan kompresi dengan penghematan hingga 60% ruang disk dari ukuran file asli. Pada beberapa kesempatan, rasio kompresi tertinggi adalah pilihan terbaik, meskipun harus dibayar dengan dekompresi yang lebih lama saat memulihkan.

Fitur Bonus:Verifikasi Cadangan Otomatis

Seperti yang dikatakan sysadmin lama - Cadangan bukanlah cadangan jika tidak dapat dipulihkan. Verifikasi cadangan adalah sesuatu yang biasanya diabaikan oleh banyak orang. Beberapa sysadmin telah mengembangkan rutinitas internal untuk ini, biasanya lebih manual daripada otomatis. Mengotomatiskan itu sulit, terutama karena kerumitan operasi secara keseluruhan - mulai dari penyediaan host, instalasi dan persiapan MySQL, transfer file cadangan, dekompresi, operasi pemulihan, prosedur verifikasi, dan akhirnya pembersihan sistem setelah proses. Semua kerepotan ini membuat orang mengabaikan aspek penting dari cadangan yang andal. Secara umum, uji pemulihan cadangan harus dilakukan setidaknya sebulan sekali, atau jika terjadi perubahan signifikan dalam ukuran data atau struktur basis data. Temukan jadwal yang sesuai untuk Anda dan formalkan dengan acara terjadwal.

ClusterControl dapat mengotomatiskan verifikasi cadangan dengan melakukan pemulihan pada host baru, tanpa mengorbankan prosedur verifikasi yang disebutkan di atas. Ini dapat dilakukan setelah beberapa penundaan, atau tepat setelah pencadangan selesai. Ini akan melaporkan status pencadangan berdasarkan kode keluar dari operasi pemulihan, melakukan penonaktifan otomatis jika pencadangan diverifikasi, atau membiarkan host yang dipulihkan berjalan sehingga Anda melakukan verifikasi manual tambahan pada data.

Saat membuat atau menjadwalkan pencadangan, Anda akan memiliki opsi tambahan jika "Verifikasi Cadangan" diaktifkan:

Jika "Install Database Software" diaktifkan, ClusterControl akan menghapus instalasi MySQL yang ada pada host target dan menginstal ulang software database dengan versi yang sama dengan server MySQL yang ada. Jika tidak, jika Anda memiliki pengaturan khusus untuk host yang dipulihkan, Anda dapat melewati opsi ini. Opsi lainnya cukup jelas.

Fitur Bonus:Jangan Lupakan PostgreSQL

Selain semua fungsionalitas hebat ini untuk MySQL dan MariaDB ClusterControl 1.5, kini juga menyediakan PostgreSQL dengan metode pencadangan tambahan (pg_basebackup) yang dapat digunakan untuk pencadangan biner online. Cadangan yang diambil dengan pg_basebackup dapat digunakan nanti untuk pemulihan tepat waktu dan sebagai titik awal untuk pengiriman log atau server siaga replikasi streaming.


Itu saja untuk saat ini. Cobalah ClusterControl v1.5, mainkan fitur-fitur baru, dan beri tahu kami pendapat Anda.


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Bagian 1:Klasifikasi Gambar dengan Server MariaDB dan TensorFlow – Gambaran Umum

  2. 2 Cara Mendaftar semua Fungsi di MariaDB

  3. Opsi Pencadangan Cloud untuk Database MySQL &MariaDB

  4. Cara Menjalankan SHOW LOCALES di MariaDB

  5. Migrasi dari Oracle Database ke MariaDB - Yang Harus Anda Ketahui