Bagaimana Anda biasanya membuat cadangan database Anda?


8

Saya menggunakan mysql

Seberapa sering Anda membuat cadangan database Anda?

Bagaimana Anda biasanya membuat cadangan basis data Anda?

Ekspor semua data ke dalam format sql atau cvs dan simpan di dalam folder ??

Jawaban:


11

Jika Anda ingin melakukan backup MySQL dengan benar, tanpa downtime, Anda harus mereplikasi database ke server cadangan. Itu tidak harus sangat kuat, hanya perlu mengatasi beban tulis dari database master Anda. Anda seharusnya tidak menggunakan server ini dalam produksi. Jika replikasi tidak pernah mengikuti, Anda memerlukan server yang lebih kuat. Anda dapat memeriksa dengan membandingkan file log dan posisi dari output

 > SHOW MASTER STATUS\G

pada master dan

 > SHOW SLAVE STATUS\G

pada budak. Saya pikir MySQL5 akan menunjukkan lag dari SHOW SLAVE STATUS.

Ketika Anda senang bahwa budak Anda mengikuti, Anda dapat melakukan backup dengan melakukan

  1. Hentikan replikasi dengan SLAVE STOP;pada slave
  2. Lakukan mysqldump --optpada server slave.
  3. Mulai replikasi lagi dengan SLAVE START;pada slave

Jika Anda melakukan ini, maka Anda akan memiliki cadangan yang konsisten dari basis data Anda. Metode ini mencegah database yang berbeda atau lebih buruk lagi, tabel yang berbeda dalam database yang sama tidak sinkron dan mencegah downtime dengan mengunci tabel untuk penulisan saat Anda melakukan backup.

Manfaat yang bagus dari pengaturan ini adalah Anda memiliki salinan basis data yang dapat Anda gunakan untuk menjalankan kueri yang panjang dan mahal yang tidak akan memengaruhi layanan langsung Anda.

Beberapa tips acak:

  • Jangan tergoda untuk melakukan backup berbasis file dari file data mysql. Ini lebih merepotkan daripada nilainya dan dump MySQL lebih fleksibel.
  • Hati-hati mysqldump mengunci tabel selama dumping.
  • Waspadalah terhadap inkonsistensi dalam dump kecuali Anda mengunci setiap tabel selama dump Anda
  • Gunakan mysqldump --opt, karena biasanya cara tercepat untuk mengimpor SQL yang dihasilkan
  • Buang sesering mungkin. Kami membuang setiap hari karena kami memiliki data 40GB +.
  • Uji kesedihan Anda di server cadangan sesekali untuk memastikannya berhasil.

2
Seconds_Behind_Master dari SHOW SLAVE STATUS tersedia di 4.1.9 dan yang lebih baru.
Dan Carley

+1 pada replikasi dan kesedihan biasa. Saya merasa relatif tidak menyakitkan untuk mulai bekerja pertama kali (tanpa banyak pengalaman mysql sebelumnya). Saya tidak sepenuhnya setuju pada backup file, Jika Anda memiliki ruang untuk melakukan keduanya maka lakukan, backup berbasis file akan lebih mudah untuk membangun kembali server baru dengan jika server database Anda asplodes, masing-masing sql dumps untuk setiap database akan lebih berguna jika Anda perlu mengembalikan data bahwa seseorang telah hilang.
theotherreceive

3

Saya menggunakan skrip yang digunakan mysqldumpuntuk mengekstrak data / skema ke file untuk setiap database. Data tersebut didukung oleh cadangan netbackup normal untuk direkam. Anda jelas dapat menambahkan lonceng dan peluit lebih lanjut tetapi ini hanya dump dasar sederhana.

#!/bin/sh
# Find out what databases are in mysql and back them up
# Delete old backups


STARTTIME=` date +%Y%m%d-%H%M `

#BACKUP_DIR="/usr/local/db_backups"
BACKUP_DIR="/var/local/db_backups"
LOGFILE="/var/log/db_backups.log"
USER="root"
PASSWD="<password>"
KEEP="7"

(
echo
echo " ---MySQL backups start ${STARTTIME} ---"
#delete any backup written more than ${KEEP} days ago
echo "Removing files over ${KEEP} days old from ${BACKUP_DIR}:"
/usr/bin/find  ${BACKUP_DIR} -mindepth 1 -mtime +${KEEP} -print -delete



echo
echo "Performing today's dumps"
#find each database running in this instance of mysl
for DB in ` echo "show databases;"|mysql -u${USER} -p${PASSWD} mysql |awk " NR>1 {print $1} " `
do
        #generate a backup file name based on the data base name
        BACKUP_FILE="${BACKUP_DIR}/${DB}-${STARTTIME}.sql"
        echo "Processing database ${DB} into file ${BACKUP_FILE}"
        # dump the database data/schema into the backup file
        mysqldump -u${USER} -p${PASSWD} --add-drop-table ${DB} > ${BACKUP_FILE}
        gzip ${BACKUP_FILE}
done

ENDTIME=` date +%Y%m%d-%H%M `
echo
echo " ---MySQL backups complete ${ENDTIME} ---"
echo
) >>  ${LOGFILE} 2>&1

1

Biasanya database didukung sekali sehari jika harus dihentikan, dan kemudian cadangan ditransfer ke area penyimpanan untuk konsolidasi kemudian mereka pergi ke tape.

Pencadangan database dilakukan dengan alat asli yang disediakan dengan mesin database sebagian besar waktu.

Cadangan tidak boleh disimpan di server dengan data jika terjadi kegagalan perangkat keras.

Sangat disarankan untuk memiliki replika terbaru dari server database Anda jika memungkinkan, lebih baik memiliki macanism failover untuk database produksi.

Untuk perangkat lunak, misalnya Anda dapat melihat bacula atau zmanda


1

Penyiapan standar kami adalah HA cluster dengan dua basis data satu replikasi ke yang lain yang hanya baca.

Kami melakukan pencadangan penuh sekali sehari dan kemudian memiliki kebijakan per pelanggan untuk menghapus cadangan lama, umumnya kami menyimpan 4 cadangan harian terakhir (untuk bertahan di akhir pekan;), 4 minggu terakhir dan 4 minggu pertama terakhir dalam sebulan. Setelah itu satu atau dua dump setahun akan disimpan ke arsip untuk disimpan selamanya.

Kami juga menyimpan log replikasi selama berapa lama kami mampu untuk menyimpan ruang disk. Mereka juga sangat berguna sebagai alat debugging karena mereka merekam dengan tepat siapa yang mengubah apa dan kapan.

Secara teoritis semua yang Anda butuhkan adalah satu cadangan penuh dan semua log replikasi untuk dapat melakukan pemulihan waktu, tetapi cadangan lengkap yang lebih sering akan mempercepat pemulihan.

Salah satu trik rapi dengan cadangan adalah dengan menggunakan tabel innodb dan - parameter tunggal-transaksi untuk dump mysql, dengan cara itu cadangan tidak akan memblokir basis data saat sedang berjalan.



1

Seluruh tujuan pencadangan adalah untuk dapat memulihkan.

Saya tidak akan menganjurkan pembuangan CSV sebagai solusi cadangan; semua itu akan memberi Anda data mentah. Ada banyak lagi di samping itu, terutama dengan database. Deskripsi tabel, tampilan, procs tersimpan, sebut saja. Jika Anda tidak memiliki ini juga, Anda tidak akan bisa mendapatkannya kembali dengan sukses. Ada juga aplikasi RDBMS dan konfigurasi untuk dipertimbangkan. Anda mungkin memiliki sejumlah besar tambalan, yang juga harus Anda gunakan di lingkungan pemulihan untuk mencapai taraf yang sama. Anda mungkin menjalankan beberapa konfigurasi khusus yang ditentukan oleh persyaratan aplikasi Anda. Anda bahkan mungkin memiliki satu set pengaturan OS tertentu yang diperlukan agar database Anda berjalan secara optimal. Semua ini juga perlu dikembalikan, dan kecuali Anda memiliki solusi cadangan yang mampu melakukannya, penundaan lebih lanjut dalam waktu pemulihan Anda,

Untuk cadangan basis data (dan cadangan secara umum), saya selalu lebih suka menggunakan perangkat lunak cadangan "nyata" yang dapat menangani semua ini.


0

Baru-baru ini, saya mengelola server MySQL di EC2. Kami menyiapkan snapshot EBS pada pekerjaan cron 15 menit, 3-5 foto disimpan.

Ketika kami melakukan server MySQL 'tradisional', kami membuat cadangan setiap hari melalui MySQl-ZRM. Cadangan pada dasarnya adalah mysqldumps, yang dikirim ke tape, SAN, dll, tergantung pada kebutuhan pelanggan.

Kedua metode dapat dilakukan tanpa menghentikan basis data.



0

Kami melakukan backup dua kali sehari dan juga menjalankan backup log setiap 10-15 menit.

Keuntungan dari metode ini adalah Anda dapat memulihkan dari salah satu cadangan dua kali sehari dan kemudian menerapkan file log hingga 15 menit terakhir paling lambat. Dengan cara ini Anda meminimalkan jumlah data yang bisa Anda hilangkan.

Namun, seberapa sering Anda membuat cadangan data terserah Anda. Berapa banyak data yang Anda merasa nyaman untuk hilang? Jika Anda mampu kehilangan data senilai satu hari maka buatlah cadangan sekali sehari. Data tidak pernah berubah? Maka Anda hanya perlu satu salinan!

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.