Ketersediaan Tinggi adalah suatu keharusan akhir-akhir ini karena sebagian besar organisasi tidak dapat membiarkan dirinya kehilangan datanya. Ketersediaan Tinggi, bagaimanapun, selalu disertai dengan label harga (yang dapat sangat bervariasi.) Setiap penyiapan yang memerlukan tindakan hampir segera biasanya memerlukan lingkungan yang mahal yang akan mencerminkan secara tepat penyiapan produksi. Tapi, ada pilihan lain yang bisa lebih murah. Ini mungkin tidak memungkinkan peralihan langsung ke kluster pemulihan bencana, tetapi tetap memungkinkan kelangsungan bisnis (dan tidak akan menguras anggaran.)
Contoh jenis penyiapan ini adalah lingkungan DR "siap siaga". Ini memungkinkan Anda untuk mengurangi pengeluaran Anda sambil tetap dapat menghidupkan lingkungan baru di lokasi eksternal jika terjadi bencana. Dalam posting blog ini kami akan mendemonstrasikan cara membuat pengaturan seperti itu.
Pengaturan Awal
Mari kita asumsikan kita memiliki pengaturan Replikasi MySQL Master / Slave yang cukup standar di pusat data kita sendiri. Ini adalah pengaturan yang sangat tersedia dengan ProxySQL dan Keepalive untuk penanganan IP Virtual. Risiko utama adalah bahwa pusat data akan menjadi tidak tersedia. Ini adalah DC kecil, mungkin hanya satu ISP tanpa BGP. Dan dalam situasi ini, kami akan berasumsi bahwa jika perlu waktu berjam-jam untuk mengembalikan database, tidak apa-apa selama mungkin untuk mengembalikannya.
Untuk menyebarkan cluster ini kami menggunakan ClusterControl, yang dapat Anda unduh secara gratis. Untuk lingkungan DR kami, kami akan menggunakan EC2 (tetapi bisa juga penyedia cloud lainnya.)
Tantangan
Masalah utama yang harus kita tangani adalah bagaimana kita harus memastikan bahwa kita memiliki data baru untuk memulihkan database kita di lingkungan pemulihan bencana? Tentu saja, idealnya kita memiliki slave replikasi dan berjalan di EC2... tetapi kemudian kita harus membayarnya. Jika anggaran kami terbatas, kami dapat mencoba menyiasatinya dengan cadangan. Ini bukan solusi sempurna karena, dalam skenario terburuk, kami tidak akan pernah dapat memulihkan semua data.
Yang kami maksud dengan "skenario kasus terburuk" adalah situasi di mana kami tidak akan memiliki akses ke server database asli. Jika kami dapat menjangkau mereka, data tidak akan hilang.
Solusi
Kita akan menggunakan ClusterControl untuk menyiapkan jadwal pencadangan guna mengurangi kemungkinan hilangnya data. Kami juga akan menggunakan fitur ClusterControl untuk mengunggah cadangan ke cloud. Jika pusat data tidak tersedia, kami berharap penyedia cloud yang kami pilih dapat dijangkau.
Mengatur Jadwal Pencadangan di ClusterControl
Pertama, kita harus mengonfigurasi ClusterControl dengan kredensial cloud kita.
Kita dapat melakukannya dengan menggunakan “Integrasi” dari menu sebelah kiri.
Anda dapat memilih Amazon Web Services, Google Cloud atau Microsoft Azure sebagai cloud Anda ingin ClusterControl mengunggah cadangan. Kami akan melanjutkan dengan AWS di mana ClusterControl akan menggunakan S3 untuk menyimpan cadangan.
Kita kemudian harus memberikan ID kunci dan rahasia kunci, pilih wilayah default dan pilih nama untuk kumpulan kredensial ini.
Setelah ini selesai, kita dapat melihat kredensial yang baru saja kita tambahkan tercantum di Kontrol Cluster.
Sekarang, kita akan melanjutkan dengan mengatur jadwal backup.
ClusterControl memungkinkan Anda membuat cadangan segera atau menjadwalkannya. Kami akan menggunakan opsi kedua. Yang kami inginkan adalah membuat jadwal berikut:
- Pencadangan penuh dibuat sekali sehari
- Pencadangan tambahan dibuat setiap 10 menit.
Idenya seperti berikut. Skenario terburuk kita hanya akan kehilangan 10 menit lalu lintas. Jika pusat data menjadi tidak tersedia dari luar tetapi akan berfungsi secara internal, kami dapat mencoba menghindari kehilangan data dengan menunggu 10 menit, menyalin cadangan tambahan terbaru di beberapa laptop dan kemudian kami dapat mengirimkannya secara manual ke basis data DR kami menggunakan bahkan tethering telepon dan koneksi seluler untuk mengatasi kegagalan ISP. Jika kami tidak dapat mengeluarkan data dari pusat data lama untuk beberapa waktu, ini dimaksudkan untuk meminimalkan jumlah transaksi yang harus kami gabungkan secara manual ke dalam basis data DR.
Kita mulai dengan pencadangan penuh yang akan dilakukan setiap hari pada pukul 2:00 pagi. Kami akan menggunakan master untuk mengambil cadangan, kami akan menyimpannya di controller di bawah direktori /root/backups/. Kami juga akan mengaktifkan opsi “Unggah Cadangan ke cloud”.
Selanjutnya, kita ingin membuat beberapa perubahan pada konfigurasi default. Kami memutuskan untuk menggunakan host failover yang dipilih secara otomatis (jika master kami tidak tersedia, ClusterControl akan menggunakan node lain yang tersedia). Kami juga ingin mengaktifkan enkripsi karena kami akan mengirimkan cadangan kami melalui jaringan.
Kemudian kita harus memilih kredensial, pilih bucket S3 yang ada atau buat yang baru jika diperlukan.
Kami pada dasarnya mengulangi proses untuk pencadangan tambahan, kali ini kami menggunakan dialog “Lanjutan” untuk menjalankan pencadangan setiap 10 menit.
Setelan lainnya serupa, kami juga dapat menggunakan kembali bucket S3.
Jadwal pencadangan terlihat seperti di atas. Kita tidak perlu memulai full backup secara manual, ClusterControl akan menjalankan incremental backup sesuai jadwal dan jika mendeteksi tidak ada full backup yang tersedia, ClusterControl akan menjalankan full backup bukan incremental.
Dengan penyiapan seperti itu, kami dapat mengatakan bahwa kami dapat memulihkan data pada sistem eksternal mana pun dengan perincian 10 menit.
Pemulihan Cadangan Manual
Jika kebetulan Anda perlu memulihkan cadangan pada instance pemulihan bencana, ada beberapa langkah yang harus Anda ambil. Kami sangat menyarankan untuk menguji proses ini dari waktu ke waktu, memastikannya bekerja dengan benar dan Anda mahir dalam menjalankannya.
Pertama, kita harus menginstal alat baris perintah AWS di server target kita:
[email protected]:~# apt install python3-pip
[email protected]:~# pip3 install awscli --upgrade --userKemudian kita harus mengonfigurasinya dengan kredensial yang tepat:
[email protected]:~# ~/.local/bin/aws configure
AWS Access Key ID [None]: yourkeyID
AWS Secret Access Key [None]: yourkeySecret
Default region name [None]: us-west-1
Default output format [None]: jsonSekarang kita dapat menguji apakah kita memiliki akses ke data di bucket S3 kita:
[email protected]:~# ~/.local/bin/aws s3 ls s3://drbackup/
PRE BACKUP-1/
PRE BACKUP-2/
PRE BACKUP-3/
PRE BACKUP-4/
PRE BACKUP-5/
PRE BACKUP-6/
PRE BACKUP-7/Sekarang, kita harus mendownload datanya. Kami akan membuat direktori untuk cadangan - ingat, kami harus mengunduh seluruh set cadangan - mulai dari cadangan lengkap hingga tambahan terakhir yang ingin kami terapkan.
[email protected]:~# mkdir backups
[email protected]:~# cd backups/Sekarang ada dua pilihan. Kami dapat mengunduh cadangan satu per satu:
[email protected]:~# ~/.local/bin/aws s3 cp s3://drbackup/BACKUP-1/ BACKUP-1 --recursive
download: s3://drbackup/BACKUP-1/cmon_backup.metadata to BACKUP-1/cmon_backup.metadata
Completed 30.4 MiB/36.2 MiB (4.9 MiB/s) with 1 file(s) remaining
download: s3://drbackup/BACKUP-1/backup-full-2019-08-20_113009.xbstream.gz.aes256 to BACKUP-1/backup-full-2019-08-20_113009.xbstream.gz.aes256
[email protected]:~# ~/.local/bin/aws s3 cp s3://drbackup/BACKUP-2/ BACKUP-2 --recursive
download: s3://drbackup/BACKUP-2/cmon_backup.metadata to BACKUP-2/cmon_backup.metadata
download: s3://drbackup/BACKUP-2/backup-incr-2019-08-20_114009.xbstream.gz.aes256 to BACKUP-2/backup-incr-2019-08-20_114009.xbstream.gz.aes256Kami juga dapat, terutama jika Anda memiliki jadwal rotasi yang ketat, menyinkronkan semua isi ember dengan apa yang kami miliki secara lokal di server:
[email protected]:~/backups# ~/.local/bin/aws s3 sync s3://drbackup/ .
download: s3://drbackup/BACKUP-2/cmon_backup.metadata to BACKUP-2/cmon_backup.metadata
download: s3://drbackup/BACKUP-4/cmon_backup.metadata to BACKUP-4/cmon_backup.metadata
download: s3://drbackup/BACKUP-3/cmon_backup.metadata to BACKUP-3/cmon_backup.metadata
download: s3://drbackup/BACKUP-6/cmon_backup.metadata to BACKUP-6/cmon_backup.metadata
download: s3://drbackup/BACKUP-5/cmon_backup.metadata to BACKUP-5/cmon_backup.metadata
download: s3://drbackup/BACKUP-7/cmon_backup.metadata to BACKUP-7/cmon_backup.metadata
download: s3://drbackup/BACKUP-3/backup-incr-2019-08-20_115005.xbstream.gz.aes256 to BACKUP-3/backup-incr-2019-08-20_115005.xbstream.gz.aes256
download: s3://drbackup/BACKUP-1/cmon_backup.metadata to BACKUP-1/cmon_backup.metadata
download: s3://drbackup/BACKUP-2/backup-incr-2019-08-20_114009.xbstream.gz.aes256 to BACKUP-2/backup-incr-2019-08-20_114009.xbstream.gz.aes256
download: s3://drbackup/BACKUP-7/backup-incr-2019-08-20_123008.xbstream.gz.aes256 to BACKUP-7/backup-incr-2019-08-20_123008.xbstream.gz.aes256
download: s3://drbackup/BACKUP-6/backup-incr-2019-08-20_122008.xbstream.gz.aes256 to BACKUP-6/backup-incr-2019-08-20_122008.xbstream.gz.aes256
download: s3://drbackup/BACKUP-5/backup-incr-2019-08-20_121007.xbstream.gz.aes256 to BACKUP-5/backup-incr-2019-08-20_121007.xbstream.gz.aes256
download: s3://drbackup/BACKUP-4/backup-incr-2019-08-20_120007.xbstream.gz.aes256 to BACKUP-4/backup-incr-2019-08-20_120007.xbstream.gz.aes256
download: s3://drbackup/BACKUP-1/backup-full-2019-08-20_113009.xbstream.gz.aes256 to BACKUP-1/backup-full-2019-08-20_113009.xbstream.gz.aes256Seperti yang Anda ingat, cadangan dienkripsi. Kita harus memiliki kunci enkripsi yang disimpan di ClusterControl. Pastikan Anda menyimpan salinannya di tempat yang aman, di luar pusat data utama. Jika Anda tidak dapat mencapainya, Anda tidak akan dapat mendekripsi cadangan. Kuncinya dapat ditemukan di konfigurasi ClusterControl:
[email protected]:~# grep backup_encryption_key /etc/cmon.d/cmon_1.cnf
backup_encryption_key='aoxhIelVZr1dKv5zMbVPLxlLucuYpcVmSynaeIEeBnM='Ini dikodekan menggunakan base64 sehingga kita harus mendekodenya terlebih dahulu dan menyimpannya dalam file sebelum kita dapat mulai mendekripsi cadangan:
echo "aoxhIelVZr1dKv5zMbVPLxlLucuYpcVmSynaeIEeBnM=" | openssl enc -base64 -d> lulus
Sekarang kita dapat menggunakan kembali file ini untuk mendekripsi cadangan. Untuk saat ini, katakanlah kita akan melakukan satu pencadangan penuh dan dua pencadangan tambahan.
mkdir 1
mkdir 2
mkdir 3
cat BACKUP-1/backup-full-2019-08-20_113009.xbstream.gz.aes256 | openssl enc -d -aes-256-cbc -pass file:/root/backups/pass | zcat | xbstream -x -C /root/backups/1/
cat BACKUP-2/backup-incr-2019-08-20_114009.xbstream.gz.aes256 | openssl enc -d -aes-256-cbc -pass file:/root/backups/pass | zcat | xbstream -x -C /root/backups/2/
cat BACKUP-3/backup-incr-2019-08-20_115005.xbstream.gz.aes256 | openssl enc -d -aes-256-cbc -pass file:/root/backups/pass | zcat | xbstream -x -C /root/backups/3/Kami memiliki data yang didekripsi, sekarang kami harus melanjutkan dengan menyiapkan server MySQL kami. Idealnya, ini harus versi yang sama persis seperti pada sistem produksi. Kami akan menggunakan Server Percona untuk MySQL:
cd ~
wget https://repo.percona.com/apt/percona-release_latest.generic_all.deb
sudo dpkg -i percona-release_latest.generic_all.deb
apt-get update
apt-get install percona-server-5.7Tidak ada yang rumit, hanya instalasi biasa. Setelah selesai dan siap, kita harus menghentikannya dan menghapus isi direktori datanya.
service mysql stop
rm -rf /var/lib/mysql/*Untuk memulihkan cadangan, kita memerlukan Xtrabackup - alat yang digunakan CC untuk membuatnya (setidaknya untuk Perona dan Oracle MySQL, MariaDB menggunakan MariaBackup). Penting bahwa alat ini diinstal dalam versi yang sama seperti di server produksi:
apt install percona-xtrabackup-24Hanya itu yang harus kita persiapkan. Sekarang kita dapat mulai memulihkan cadangan. Dengan pencadangan tambahan, penting untuk diingat bahwa Anda harus menyiapkan dan menerapkannya di atas cadangan dasar. Base backup juga harus disiapkan. Sangat penting untuk menjalankan persiapan dengan opsi '--apply-log-only' untuk mencegah xtrabackup menjalankan fase rollback. Jika tidak, Anda tidak akan dapat menerapkan pencadangan tambahan berikutnya.
xtrabackup --prepare --apply-log-only --target-dir=/root/backups/1/
xtrabackup --prepare --apply-log-only --target-dir=/root/backups/1/ --incremental-dir=/root/backups/2/
xtrabackup --prepare --target-dir=/root/backups/1/ --incremental-dir=/root/backups/3/Dalam perintah terakhir kami mengizinkan xtrabackup untuk menjalankan rollback dari transaksi yang belum selesai - kami tidak akan menerapkan cadangan tambahan lagi setelahnya. Sekarang saatnya untuk mengisi direktori data dengan cadangan, mulai MySQL dan lihat apakah semuanya berfungsi seperti yang diharapkan:
[email protected]:~/backups# mv /root/backups/1/* /var/lib/mysql/
[email protected]:~/backups# chown -R mysql.mysql /var/lib/mysql
[email protected]:~/backups# service mysql start
[email protected]:~/backups# mysql -ppass
mysql: [Warning] Using a password on the command line interface can be insecure.
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 6
Server version: 5.7.26-29 Percona Server (GPL), Release '29', Revision '11ad961'
Copyright (c) 2009-2019 Percona LLC and/or its affiliates
Copyright (c) 2000, 2019, Oracle and/or its affiliates. All rights reserved.
Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
mysql> show schemas;
+--------------------+
| Database |
+--------------------+
| information_schema |
| mysql |
| performance_schema |
| proxydemo |
| sbtest |
| sys |
+--------------------+
6 rows in set (0.00 sec)
mysql> select count(*) from sbtest.sbtest1;
+----------+
| count(*) |
+----------+
| 10506 |
+----------+
1 row in set (0.01 sec)Seperti yang Anda lihat, semuanya baik-baik saja. MySQL memulai dengan benar dan kami dapat mengaksesnya (dan data ada di sana!) Kami berhasil mengembalikan database kami dan berjalan di lokasi terpisah. Total waktu yang dibutuhkan sangat bergantung pada ukuran data - kami harus mengunduh data dari S3, mendekripsi dan mendekompresinya, dan akhirnya menyiapkan cadangan. Namun, ini adalah opsi yang sangat murah (Anda harus membayar hanya untuk data S3) yang memberi Anda opsi untuk kelangsungan bisnis jika terjadi bencana.
