Gangguan produksi hampir pasti akan terjadi pada suatu saat. Kami mengetahuinya sehingga kami merencanakan pencadangan, membuat database siaga pemulihan, mengonversi instans tunggal menjadi kluster.
Mengakui perlunya skenario pemulihan yang tepat, kami harus menganalisis kemungkinan linimasa bencana dan skenario kegagalan serta menerapkan langkah-langkah untuk meningkatkan basis data Anda. Eksekusi pemadaman yang direncanakan dapat membantu mempersiapkan, mendiagnosis, dan memulihkan dari yang berikutnya. Untuk mengurangi dampak waktu henti, organisasi memerlukan rencana pemulihan yang tepat, yang akan mencakup semua faktor yang diperlukan untuk menghidupkan layanan.
Manajemen Pencadangan tidak semudah hanya menjadwalkan pekerjaan pencadangan. Ada banyak faktor yang perlu dipertimbangkan, seperti penyimpanan, penyimpanan, verifikasi, dan apakah cadangan yang Anda ambil bersifat fisik atau logis dan apa yang mudah diabaikan keamanannya.
Banyak organisasi memvariasikan pendekatan mereka terhadap pencadangan, mencoba untuk memiliki kombinasi pencadangan citra server (snapshot), pencadangan logis dan fisik yang disimpan di beberapa lokasi. Ini untuk menghindari bencana lokal atau regional yang akan menghapus database dan cadangan kami yang disimpan di pusat data yang sama.
Kami ingin membuatnya aman. Data dan cadangan harus dienkripsi. Tetapi ada banyak implikasi ketika kedua opsi itu ada. Dalam artikel ini, kita akan melihat prosedur pencadangan saat menangani database terenkripsi.
Encryption-at-Rest untuk Server Percona untuk MySQL 8.0
Mulai dari MySQL 5.7.11, versi komunitas MySQL mulai mendukung enkripsi tablespace InnoDB. Ini disebut Enkripsi Tablespace Transparan atau disebut sebagai Encryption-at-Rest.
Perbedaan utama dibandingkan dengan versi perusahaan adalah cara kunci disimpan - kunci tidak terletak di brankas yang aman, yang diperlukan untuk kepatuhan terhadap peraturan. Hal yang sama berlaku untuk Percona Server, mulai versi 5.7.11, dimungkinkan untuk mengenkripsi tablespace InnoDB. Di Percona Server 8.0, dukungan untuk mengenkripsi log biner telah sangat diperluas. Versi 8.0 ditambahkan
(Per dokumen rilis Percona 8.0):
- Enkripsi File Sementara
- InnoDB Undo Tablespace Encryption
- Enkripsi Tablespace Sistem InnoDB (Enkripsi Tablespace Sistem InnoDB)
- default_table_encryption =OFF/ON (Enkripsi Tablespace Umum)
- table_encryption_privilege_check =OFF/ON (Memverifikasi Pengaturan Enkripsi)
- Enkripsi redo log InnoDB (hanya untuk enkripsi kunci master) (Enkripsi Redo Log)
- Enkripsi file gabungan InnoDB (Memverifikasi Pengaturan Enkripsi)
- Percona Parallel doublewrite buffer encryption (Enkripsi InnoDB Tablespace)
Bagi mereka yang tertarik dengan migrasi dari versi MySQL Enterprise ke Percona - Anda juga dapat berintegrasi dengan server Hashicorp Vault melalui plugin keyring_vault, yang cocok dengan fitur yang tersedia di Oracle edisi MySQL Enterprise.
Enkripsi data saat istirahat memerlukan plugin keyring. Ada dua opsi di sini:
- keyring_file - file datar dengan kunci enkripsi
- Plugin Keyring Vault - layanan
Cara Mengaktifkan Enkripsi Tablespace
Untuk mengaktifkan enkripsi, mulai database Anda dengan opsi --early-plugin-load:
baik dengan tangan:
$ mysqld --early-plugin-load="keyring_file=keyring_file.so"atau dengan memodifikasi file konfigurasi:
[mysqld]
early-plugin-load=keyring_file.soMemulai Percona Server 8.0 dua jenis tablespace dapat dienkripsi. Tablespace umum dan tablespace sistem. Tablespace Sys dikendalikan melalui parameter innodb_sys_tablespace_encrypt. Secara default, sys tablespace tidak dienkripsi, dan jika Anda sudah memilikinya, tidak mungkin mengonversinya ke status terenkripsi, instance baru harus dibuat (mulai instance dengan opsi --bootstrap).
Tablespace umum mendukung enkripsi salah satu dari semua tabel di tablespace atau tidak sama sekali. Tidak mungkin menjalankan enkripsi dalam mode campuran. Untuk membuat tablespace makan dengan enkripsi gunakan flag ENCRYPTION='Y/N'.
Contoh:
mysql> CREATE TABLESPACE severalnines ADD DATAFILE 'severalnines.ibd' ENCRYPTION='Y';Mencadangkan Basis Data Terenkripsi
Saat Anda menambahkan tablespace terenkripsi, Anda perlu menyertakan file keyring dalam perintah xtrabackup. Untuk melakukannya, Anda harus menentukan jalur ke file keyring sebagai nilai opsi --keyring-file-data.
$ xtrabackup --backup --target-dir=/u01/mysql/data/backup/ --user=root --keyring-file-data=/u01/secure_location/keyring_filePastikan untuk menyimpan file keyring di lokasi yang aman. Juga, pastikan untuk selalu memiliki cadangan file. Xtrabackup tidak akan menyalin file keyring di direktori backup. Untuk menyiapkan cadangan, Anda perlu membuat salinan file keyring sendiri.
Menyiapkan Cadangan
Setelah kami memiliki file cadangan, kami harus menyiapkannya untuk pemulihan. Di sini Anda juga perlu menentukan keyring-file-data.
$ xtrabackup --prepare --target-dir=/u01/mysql/data/backup/ --keyring-file-data=/u01/secure_location/keyring_fileCadangan sekarang disiapkan dan dapat dipulihkan dengan opsi --copy-back. Jika keyring telah diputar, Anda perlu memulihkan keyring (yang digunakan untuk mengambil dan menyiapkan cadangan).
Untuk menyiapkan xtrabackup cadangan, kita memerlukan akses ke keyring. Xtrabackup tidak berbicara langsung ke server MySQL dan tidak membaca file konfigurasi default my.cnf selama persiapan, tentukan pengaturan keyring melalui baris perintah:
$ xtrabackup --prepare --target-dir=/data/backup --keyring-vault-config=/etc/vault.cnfCadangan sekarang disiapkan dan dapat dipulihkan dengan opsi --copy-back:
$ xtrabackup --copy-back --target-dir=/u01/backup/ --datadir=/u01/mysql/data/Melakukan Pencadangan Inkremental
Proses pengambilan cadangan inkremental dengan enkripsi tablespace InnoDB mirip dengan pengambilan cadangan inkremental yang sama dengan tablespace yang tidak terenkripsi.
Untuk membuat pencadangan tambahan, mulailah dengan pencadangan penuh. Biner xtrabackup menulis file bernama xtrabackup_checkpoints ke direktori target pencadangan. File ini berisi baris yang menunjukkan to_lsn, yang merupakan LSN database di akhir pencadangan.
Pertama, Anda perlu membuat cadangan lengkap dengan perintah berikut:
$ xtrabackup --backup --target-dir=/data/backups/base --keyring-file-data=/var/lib/mysql-keyring/keyringSekarang setelah Anda memiliki cadangan lengkap, Anda dapat membuat cadangan tambahan berdasarkan cadangan tersebut. Gunakan perintah seperti berikut:
$ xtrabackup --backup --target-dir=/data/backups/inc1 \
--incremental-basedir=/data/backups/base \
--keyring-file-data=/var/lib/mysql-keyring/keyringDirektori /data/backups/inc1/ sekarang harus berisi file delta, seperti ibdata1.delta dan test/table1.ibd.delta.
Artinya harus jelas. Sekarang Anda dapat menggunakan direktori ini sebagai basis untuk pencadangan tambahan lainnya:
$ xtrabackup --backup --target-dir=/data/backups/inc2 \
--incremental-basedir=/data/backups/inc1 \
--keyring-file-data=/var/lib/mysql-keyring/keyringMenyiapkan Cadangan Tambahan
Sejauh ini proses backup database mirip dengan backup biasa, kecuali pada flag dimana kita menentukan lokasi file keyring.
Sayangnya, langkah --prepare untuk pencadangan tambahan tidak sama dengan pencadangan normal.
Dalam pencadangan normal, dua jenis operasi dilakukan untuk membuat basis data konsisten:transaksi yang dikomit diputar ulang dari file log terhadap file data, dan transaksi yang tidak dikomit dibatalkan. Anda harus melewati rollback transaksi yang tidak dikomit saat menyiapkan cadangan, karena transaksi yang tidak dikomit pada saat pencadangan Anda mungkin sedang berlangsung, dan kemungkinan transaksi tersebut akan dilakukan di pencadangan inkremental berikutnya. Anda harus menggunakan opsi --apply-log-only untuk mencegah fase rollback.
Jika Anda tidak menggunakan opsi --apply-log-only untuk mencegah fase rollback, maka cadangan tambahan Anda tidak akan berguna. Setelah transaksi dibatalkan, pencadangan tambahan lebih lanjut tidak dapat diterapkan.
Mulai dengan cadangan lengkap yang Anda buat, Anda dapat menyiapkannya dan kemudian menerapkan perbedaan inkremental ke dalamnya. Ingatlah bahwa Anda memiliki cadangan berikut:
/data/backups/base
/data/backups/inc1
/data/backups/inc2Untuk menyiapkan pencadangan dasar, Anda perlu menjalankan --prepare seperti biasa, tetapi mencegah fase rollback:
$ xtrabackup --prepare --apply-log-only --target-dir=/data/backups/base --keyring-file-data=/var/lib/mysql-keyring/keyringUntuk menerapkan cadangan tambahan pertama ke cadangan lengkap, Anda harus menggunakan perintah berikut:
$ xtrabackup --prepare --apply-log-only --target-dir=/data/backups/base \
--incremental-dir=/data/backups/inc1 \
--keyring-file-data=/var/lib/mysql-keyring/keyringjika gantungan kunci telah diputar antara cadangan dasar dan cadangan tambahan, Anda harus menggunakan gantungan kunci yang digunakan saat cadangan tambahan pertama diambil.
Menyiapkan cadangan tambahan kedua adalah proses yang serupa
$ xtrabackup --prepare --target-dir=/data/backups/base \
--incremental-dir=/data/backups/inc2 \
--keyring-file-data=/var/lib/mysql-keyring/keyringCatatan; --apply-log-only harus digunakan saat menggabungkan semua inkremental kecuali yang terakhir. Itu sebabnya baris sebelumnya tidak berisi opsi --apply-log-only. Bahkan jika --apply-log-only digunakan pada langkah terakhir, pencadangan akan tetap konsisten tetapi dalam hal ini server akan melakukan fase rollback.
Langkah terakhir adalah memulihkannya dengan --copy-back pilihan. Jika keyring telah diputar, Anda harus memulihkan keyring yang digunakan untuk mengambil dan menyiapkan cadangan.
Sementara metode pemulihan yang dijelaskan berfungsi, metode ini memerlukan akses ke keyring yang sama dengan yang digunakan server. Ini mungkin tidak dapat dilakukan jika pencadangan disiapkan di server yang berbeda atau di lain waktu, saat kunci di gantungan kunci dihapus, atau, dalam kasus malfungsi, saat server brankas gantungan kunci tidak tersedia sama sekali.
Opsi --transition-key=
Membuat Cadangan dengan Frasa Sandi
Contoh berikut menggambarkan bagaimana cadangan dapat dibuat dalam kasus ini:
$ xtrabackup --backup --user=root -p --target-dir=/data/backup \
--transition-key=MySecetKeyMemulihkan Cadangan dengan Kunci yang Dihasilkan
Saat memulihkan cadangan, Anda perlu membuat kunci master baru. Berikut adalah contoh untuk keyring_file:
$ xtrabackup --copy-back --target-dir=/data/backup --datadir=/data/mysql \
--transition-key=MySecetKey --generate-new-master-key \
--keyring-file-data=/var/lib/mysql-keyring/keyringDalam kasus keyring_vault, akan terlihat seperti ini:
$ xtrabackup --copy-back --target-dir=/data/backup --datadir=/data/mysql \
--transition-key=MySecetKey --generate-new-master-key \
--keyring-vault-config=/etc/vault.cnf
