Melakukan pencadangan tambahan merupakan persyaratan penting untuk basis data produksi besar. Tanpa cadangan tambahan yang aman, Anda tidak dapat meyakinkan diri sendiri bahwa Anda memiliki basis data produksi yang andal. Karena Anda harus memiliki data yang cukup untuk memulihkan database Anda dalam kasus darurat. Setelah beberapa pencarian di Internet, saya tidak dapat menemukan alat apa pun yang dapat melakukan pencadangan tambahan lengkap untuk MyISAM dan InnodB dalam lingkungan campuran jika aplikasi menggunakan kedua mesin basis data secara bersamaan (mungkin saya bukan pencari ahli di Google dan Internet). Jadi saya memutuskan untuk menulis yang ini, tetapi untuk menghindari membuang-buang waktu dan memanfaatkan solusi open-source lainnya, saya lebih suka menambahkan fitur ini ke skrip -automysqlbackup- yang merupakan skrip terbaik untuk pencadangan penuh dalam kesederhanaan dan penggunaan luas.
Mekanisme
Kami menggunakan fitur Pasca dan Pra dari automysqlbackup untuk melakukan pencadangan tambahan. Sebelum memulai full backup, mysql-backup-pre mengeksekusi query untuk mengunci seluruh database selama proses backup karena kita harus membekukan binlog untuk menghindari perubahan apapun saat backup berjalan. Nama dan posisi binlog tidak boleh berubah selama pencadangan. Posisi log biner sangat penting dalam proses pencadangan inkremental berikutnya dan akan digunakan sebagai titik awal untuk memulai pencadangan inkremental berikutnya. Setelah menyelesaikan pencadangan penuh, mysql-backup-post menghapus kunci database.
Lock Query:FLUSH TABLES DENGAN READ LOCK; PILIH TIDUR(86400)
Temukan Kueri Kunci:mysql -u[nama pengguna] -p[lulus] -e "tampilkan daftar proses" | grep "PILIH TIDUR(86400)" | awk '{print $1}'
Persyaratan
- hak root untuk menginstal paket dan memperbarui mysql.conf
- paket klien-komunitas-mysql
- instalasi automysqlbackup dan mysql-incremental
Instalasi
Instal paket mysql-community-client untuk distro Anda.
Catatan:setelah instalasi MySQL Anda harus memiliki perintah 'mysqlshow'.
Instal automysqlbackup:
download the package from https://sourceforge.net/projects/automysqlbackup/
tar -xzf [PathYouSavedTarFile] -C /tmp/
cd /tmp/
./install.sh
Selama instalasi automysqlbackup, Anda akan ditanya tentang path automysqlbackup.conf dan binernya, Anda dapat membiarkan default tanpa perubahan apa pun.
rm /etc/automysqlbackup/myserver.conf
Instal mysql-incremental:Unduh paket dari https://sourceforge.net/projects/mysqlincrementalbackup/
cd /tmp
wget http://downloads.sourceforge.net/project/mysqlincrementalbackup/mysql-incremental.tar.gz
tar xfz mysql-incremental.tar.gz
cp mysql-incremental /etc/automysqlbackup/
chmod 755 /etc/automysqlbackup/mysql-incremental
cp mysql-backup-post /etc/automysqlbackup/
chmod 755 /etc/automysqlbackup/mysql-backup-post
cp mysql-backup-pre /etc/automysqlbackup/
chmod 755 /etc/automysqlbackup/mysql-backup-pre
Perbarui automysqlbackup.conf:
Temukan parameter di bawah ini, batalkan komentar dan ubah:
CONFIG_mysql_dump_username='Mysql user name. It must has privileges to get Lock'
CONFIG_mysql_dump_password='Password'
CONFIG_backup_dir='The backup directory you want to store full and incremental backup'
CONFIG_db_names=('databaseName1' 'databaseName2' )
CONFIG_db_month_names=('databaseName1' 'databaseName2' )
CONFIG_mysql_dump_master_data=2
CONFIG_prebackup="/etc/automysqlbackup/mysql-backup-pre"
CONFIG_postbackup="/etc/automysqlbackup/mysql-backup-post"
Perbarui my.cnf:
Edit file konfigurasi MySQL:
nano /etc/mysql/my.cnf
1- Format BinLog
Karena beberapa batasan pada format STATEMENT, rekomendasi saya adalah untuk mengatur format berbasis ROW. Untuk informasi lebih lanjut, silakan lihat bagian 'pemecahan masalah' di cara ini. Anda dapat memeriksa jenis format log biner dengan menjalankan "select @@binlog_format;" pertanyaan. Untuk mengubah format logbin , Anda harus menambahkan binlog_format =ROW ke mysql.conf atau my.cnf .
2- binlog_do_db
Anda harus menentukan database yang Anda inginkan untuk memiliki perubahan terkait dalam log biner. Harap dicatat jika Anda tidak menentukan basis data apa pun, setiap perubahan pada basis data apa pun akan masuk ke log biner. Dalam hal ini, jika Anda memilih format STATEMENT, mungkin Anda mengalami masalah saat memulihkan dari cadangan inkremental dan file binlog. Anda dapat menambahkan database ke opsi ini:
binlog_do_db = DATABASENAME1 binlog_do_db = DATABASENAME2
3- expired_logs_days
Untuk memiliki file log biner untuk waktu yang lebih lama, Anda dapat meningkatkan parameter ini ke nilai yang lebih tinggi. Rekomendasi saya adalah 60 hari. Jadi Anda harus menambahkan atau mengubahnya menjadi "expire_logs_days =60".
4- log-bin
Direktori tempat log biner akan disimpan. Di versi MySQL lama, mysql-incremenetal mungkin tidak dapat menemukan jalur yang benar. Jadi jika Anda mendapatkan kesalahan tentang ini setelah menjalankan mysql-incremental, Anda harus memperbarui skrip mysql-incremental dan mengatur jalur log biner.
5- log_slave_updates
Jika Anda menyiapkan cadangan tambahan mysql di server budak, Anda harus mengaktifkan opsi ini. Biasanya, slave tidak mencatat pembaruan ke log binernya sendiri seperti yang diterima dari server master. Opsi ini memberi tahu budak untuk mencatat pembaruan yang dilakukan oleh utas SQL-nya ke log binernya sendiri. http://dev.mysql.com/doc/refman/5.1/en/replication-options-slave.html#option_mysqld_log-slave-updates
Jalankan automysqlbackup
Jalankan automysqlbackup secara manual untuk memiliki setidaknya satu backup penuh dari database yang Anda tentukan.
automysqlbackup
Setelah berhasil menjalankan perintah, periksa file /[BackupDirInAutomysqlbackup]/status/backup_info untuk informasi yang baru ditambahkan tentang pencadangan harian. Untuk detail kesalahan, periksa /var/log/Backup_Post_Pre_log . File cadangan akan disimpan di direktori /[BackupDirInAutomysqlbackup]/daily/[DatabaseName]/ .
Jalankan mysql-incremental
Jalankan mysql-incremental secara manual sekarang untuk memiliki setidaknya satu cadangan setiap jam.
mysql-incremental
Jika terjadi kesalahan, detailnya dicatat dalam file "/var/log/Backup_Incremental_Log" . File cadangan tambahan akan disimpan di direktori /[BackupDirInAutomysqlbackup]/IncrementalBackup/ .
Edit root crontab
Anda dapat menjadwalkan mysql-incremental selama lebih dari satu jam. Anda dapat menemukan total waktu pencadangan penuh dari backup_status dan kemudian berdasarkan nilai tersebut Anda menetapkan waktu jadwal yang akurat. Tentu saja mysql-incremental backup memiliki mekanisme untuk menemukan full backup yang berjalan sebelum memulai, jadi tidak ada kekhawatiran tentang konflik antara incremental dan full backup.
crontab -e
5 00 * * * root /usr/local/bin/automysqlbackup 25 * * * * root /etc/automysqlbackup/mysql-incremental
Pulihkan Basis Data
Untuk memulihkan hingga waktu tertentu (pemulihan titik waktu), pertama-tama Anda harus memulihkan satu cadangan harian penuh dan kemudian memulihkan file cadangan inkremental terkait secara berurutan. Untuk memperjelas lebih lanjut, berikut adalah langkah-langkah untuk memulihkan database testDB. Dalam skenario sampel, kami bermaksud memulihkan data kami hingga 01-05-2015 pada pukul 2 pagi. kami telah menetapkan /backup sebagai direktori cadangan utama kami dan testDB sebagai basis data target kami:
1- mysql -u root -p DatabaseName < /backup/daily/testDB/daily_DatabaseName_2015-05-16_00h05m_Saturday.sql.gz 2- mysql -u root -p DatabaseNAme < /backup/IncrementalBackup/2015-5-01_Incremental/testDB/testDB_IncrementalBackup_2015-5-01_00h25m.1 3- mysql -u root -p DatabaseNAme < /backup/IncrementalBackup/2015-5-01_Incremental/testDB/testDB_IncrementalBackup_2015-5-01_01h25m.2 4- mysql -u root -p DatabaseNAme < /backup/IncrementalBackup/2015-5-01_Incremental/testDB/testDB_IncrementalBackup_2015-5-01_02h25m.3
Catatan penting dan Pemecahan Masalah
MySQL mendukung format yang berbeda untuk log biner. Beberapa versi Mysql menggunakan 'statement-based' sebagai format binlog dimana jenis binlog ini memang memiliki beberapa keterbatasan yang harus kita perhatikan dengan baik ketika kita bermaksud menggunakannya dalam prosedur pencadangan tambahan. Ketika mysql diatur ke format basis pernyataan, itu tidak dapat memfilter dengan benar berdasarkan database. Jika Anda mengatur 'USE atau \u' untuk mengubah database dan kemudian memperbarui database lain yang tidak termasuk dalam binlog-do-db, pernyataan akan dicatat dalam file binlog bahwa itu bukan status yang diinginkan! dan akan mengekspos beberapa masalah saat memulihkan berdasarkan database tertentu dan juga jika Anda mengubah ke database lain yang tidak termasuk dalam binlog-do-db, dan memperbarui database yang termasuk dalam binlog-do-db, pernyataan tidak akan masuk ke berkas binlog. tujuan kami menambahkan database ke binlog-do-db adalah untuk memfilter berdasarkan database, tetapi tidak berfungsi seperti yang diharapkan. Jika USE atau \u tidak dieksekusi sebelum menjalankan kueri, mysqlbinlog tidak dapat mengekstrak 'perbarui kueri' yang terkait dengan satu database. Kami akan menjelaskan lebih lanjut masalah ini dengan skenario di bawah ini:
databases:
- binlog
- person (table)
- binlog2
- person (table)
binlog-do-db=binlog2 (it is supposed only change of this database are logged to binlog file)
--------Scenario 1---------
\u binlog2
insert into person (data) values ('17') ---> loged in binlog *desired state*
insert into binlog.person (data) values ('25'); ---> logged in binlog (target database is 'binlog' ) *undesired state*
--------Scenario 2---------
\u binlog
insert into person (data) values ('17') ---> is not logged in binlog *desired state*
insert into binlog2.person (data) values ('25'); ---> is not logged in binlog (target database is 'binlog2' ) *undesired state* because the binlog2 database
is begin changed, so we want to have this change,but it will not logged in logbin file
--------Scenario 3---------
if you just connect to database without any USE or \u statement, all of updates on any databases will be logged, but mysqlbinlog can not able to filter
based on specific database, so that is not desirable state for our purpose in incremental backup. Using USE or \u before executing update queries, is very
important. Because mysqlbinlog finds update queries based on USE statement in binlog file. Atasi masalah yang disebutkan
1) Dengan mendefinisikan pengguna pada basis data sedemikian rupa sehingga setiap pengguna hanya memiliki akses ke satu basis data untuk diperbarui (pengguna aplikasi) dan ketika koneksi ke basis data, nama basis data harus ditentukan. Tentu saja sebagian besar aplikasi memiliki file konfigurasi yang kredensial dan nama database diatur di dalamnya, jadi dalam hal ini Anda tidak akan memiliki akses silang pada database dan tidak akan ada kekhawatiran menggunakan "\USE atau \u ".
2) Jika Anda menggunakan format binlog berbasis baris, maka semua masalah yang disebutkan akan hilang. dengan kata lain, format berbasis baris adalah metode yang jauh lebih tepat untuk binlog. https://dev.mysql.com/doc/refman/5.1/en/replication-options-binary-log.html
File Log
Saya memang mencoba untuk mencatat semuanya dalam file log sehingga Anda dapat menemukan informasi yang cukup di log:
/var/log/Backup_Post_Pre_log
/var/log/Backup_Incremental_Log
/[SpecifiedBackupDirInAutomysqlbackup.conf]/status/backup_info
File "backup_info" berisi info terperinci tentang pencadangan dan kapan pencadangan selesai (Waktu dalam format Waktu Unix). Ini berisi nama binlog dan posisi titik waktu pencadangan dimulai, jenis pencadangan, jumlah pencadangan sejak pencadangan lengkap terakhir, dan durasi pencadangan.
Contoh backup_info:
1431043501,mysql-bin.000026,120,Daily,2015-05-08,0,24 1431044701,mysql-bin.000026,120,Hourly,2015-05-08,1,1
Berikut adalah deskripsi dari nilai yang berbeda:
1th) 1431043501 : indicates the time when the backup has been finished. You can run date --date @1431043501 command on the server the backup has been done to view it in human readable format. 2th) Mysql-bin.000026 : indicates the binary log name that backup up to this file has been done. 3th) 120 : indicates the position of binlog that backup up to this position in binary log has been done. 4th) Daily/Hourly: indicates type of backup. Daily does mean the full backup by automysqlbackup script and Hourly is done by mysql-incremental script. 5th) 2015-05-08: The date that backup has been done. This date will be used in creating directory for incremental backup and also as a base for restore hourly backups. In restoring procedure, first a full backup is restored and then sequentially other incremental backup are restored. 6th) 0 : indicates number of backups from previous full backup. 0 does mean the backup is full and others mean hourly. This number is very important in restoring procedure. 7th) 24: The backup duration in second.
Laporan Bug
Anda dapat melaporkan bug atau memberikan saran dan ulasan Anda di https://sourceforge.net/projects/mysqlincrementalbackup .