Bagaimana cara membuang database MySQL innodb yang besar secara efisien?


8

Saya mendapat server database MySQL produksi Ubuntu 10,04 di mana ukuran total database adalah 260 GB sementara ukuran partisi root sendiri 300 GB di mana DB disimpan, pada dasarnya berarti sekitar 96% dari / penuh dan tidak ada ruang tersisa untuk menyimpan dump / cadangan dll. Tidak ada disk lain yang terpasang ke server sampai sekarang.

Tugas saya adalah untuk memigrasi basis data ini ke server lain yang duduk di pusat data yang berbeda. Pertanyaannya adalah bagaimana melakukannya secara efisien dengan downtime minimum?

Saya sedang berpikir dalam garis:

  • Permintaan untuk melampirkan drive tambahan ke server dan melakukan dump di drive itu. [EDIT: Sekarang tidak mungkin.]
  • Transfer dump ke server baru, pulihkan dan buat server baru yang sudah ada untuk menyimpan data dalam sinkronisasi
  • Saat migrasi diperlukan, hentikan replikasi, perbarui konfigurasi budak untuk menerima permintaan baca / tulis dan buat server lama hanya-baca sehingga tidak akan menerima permintaan penulisan apa pun dan beri tahu pengembang aplikasi untuk memperbarui di sana konfigurasi dengan alamat IP baru untuk db.

Apa saran Anda untuk meningkatkan ini atau pendekatan lain yang lebih baik untuk tugas ini?

Jawaban:


9

Jika Anda mempertimbangkan migrasi ke yang lain DB Server dengan versi yang sama persis dari MySQL, Anda mungkin ingin rsyncyang datadirdari server lama ke server baru.

Ini akan berfungsi terlepas dari tata letak file InnoDB atau bahkan keberadaan tabel MyISAM.

  1. instal versi mysql yang sama di ServerB yang dimiliki ServerA
  2. Di ServerA, jalankan RESET MASTER;untuk menghapus semua log biner sebelum proses rsycn. Jika pencatatan biner tidak diaktifkan, Anda dapat melewati langkah ini.
  3. Di ServerA, jalankan SET GLOBAL innodb_max_dirty_pages_pct = 0;dari mysql dan sekitar 10 menit (Ini membersihkan halaman kotor dari Pool Buffer InnoDB. Ini juga membantu melakukan shutdown mysql lebih cepat) Jika database Anda semua MyISAM, Anda dapat melewati langkah ini.
  4. rsync / var / lib / mysql dari ServerA ke / var / lib / mysql di ServerB
  5. Ulangi Langkah 3 hingga rsync membutuhkan waktu kurang dari 1 menit
  6. service mysql stop di ServerA
  7. Lakukan satu rsync lagi
  8. scp ServerA: /etc/my.cnf ke ServerB: / etc /.
  9. service mysql start di ServerB
  10. service mysql start pada ServerA (opsional)

Pada dasarnya, inilah yang diinginkan skrip seperti ini

mysql -u... -p... -e"RESET MASTER;"
mysql -u... -p... -e"SET GLOBAL innodb_max_dirty_pages_pct = 0;"
RSYNCSTOTRY=10
cd /var/lib/mysql
X=0
while [ ${X} -lt ${RSYNCSTOTRY} ]
do
    X=`echo ${X}+1|bc`
    rsync -r * targetserver:/var/lib/mysql/.
    sleep 60
done
service mysql stop
rsync -r * targetserver:/var/lib/mysql/.
service mysql start

Seorang anggota DBA StackExchange berkata saya harus menjauh dari FLUSH TABLES WITH READ LOCK;sesuatu yang ada di mysqlperformanceblog.com

Saya membaca dan mengetahui bahwa SELECT terhadap tabel InnoDB di tengah-tengah FLUSH TABLES WITH READ LOCK;masih dapat memungkinkan penulisan terjadi dalam beberapa cara. Seperti yang ditunjukkan dalam komentar oleh Arlukin , LVM akan bekerja dengan baik FLUSH TABLES WITH READ LOCKpada InnoDB (+1 untuk komentarnya).

Untuk semua pengguna non-LVM, Anda OK dengan database semua-MyISAM untuk digunakan FLUSH TABLES WITH READ LOCK;. Untuk InnoDB, tetap --single-tranactiongunakan di mysqldumps.


2
Itulah cara kami melakukannya, ketika kami perlu menyinkronkan pengaturan master-slave secara manual. Bekerja sangat bagus. Tetapi pada server terbaru kami, kami menggunakan snapshot LVM, jadi kami tidak perlu menghentikan server. Tepat sebelum melakukan LVM-snapshot kami menjalankan "FLUSH TABLES WITH READ LOCK", jadi file-file tersebut boleh di-copy. Lvm-snapshot juga sangat bagus jika Anda ingin menyalin semua file dalam tujuan cadangan. Jadi siapkan server baru Anda dengan LVM, dan tambahkan beberapa ruang ekstra untuk dapat melakukan snapshot.
Arlukin

Terima kasih atas jawaban terinci. Bagaimana jika versi MySQL berbeda? Yang lebih tua adalah 5.1 dengan ubuntu 10.04 sementara di yang lebih baru saya bersedia menggunakan 12.04 dengan standar 5.5. Pendekatan apa yang Anda rekomendasikan? Juga melampirkan drive tambahan sudah tidak dipertanyakan sekarang sehingga data perlu dikirim dari jarak jauh apakah dengan dump / rsync atau cara lain.
Jagbir

1

Sebuah dump dan restore dari database yang ukurannya akan memakan waktu berjam-jam. Saya akan, Tergantung pada versi mysql selama penambahan nomor versi dan tidak ada lompatan dalam jumlah revisi utama. Anda harus dapat mengambil file database mentah di / var / lib / mysql dan meletakkannya di server baru, mengatur izin dan menjalankan server dengan saklar --skip-grant-tables. Tambahkan hibah yang diperlukan untuk pengguna yang mencerminkan alamat IP baru kemudian mulai kembali secara normal.

Saya akan membahas ukuran basis data Anda karena terlalu besar untuk efisien.


Ada 4 database yang memiliki ukuran sekitar 50-90 GB sehingga ukuran keseluruhan 260 GB. Mungkin tidak efisien tapi saya harus menjalaninya seperti sekarang. Juga versi MySQL berbeda, apa yang Anda sarankan dalam kasus itu?
Jagbir

Jika versi mysql berbeda, lakukan dry run terlebih dahulu dan ujilah dengan seksama asalkan nomor versi di server baru lebih tinggi daripada yang lama Anda harusnya ok. Jika tidak berhasil maka Anda mungkin terjebak menggunakan mysqldump && restore.
James Park-Watt

1

Anda dapat mengikuti langkah-langkah ini untuk memigrasi basis data InnoDB yang sangat besar ini.

  • Instal SSHFS dan pasang partisi server jarak jauh yang relevan di server produksi
  • Gunakan Percona XtraBackup untuk mendapatkan hotcopy dari database InnoDB dan langsung menyimpannya ke direktori yang diinstal SSHFS
  • Tugas ini akan memakan waktu beberapa jam. Untuk meminimalkan pengaruh skrip hotcopy pada server langsung, tetapkan prioritas rendah untuk itu menggunakan renice

    $ renice -n 5 -p <SCRIPT-PID>

  • Pastikan kedua server menjalankan rilis yang sama dari server MySQL.
  • Setelah hotcopy selesai, Anda dapat mengembalikannya di server baru memulai proses replikasi

Anda mungkin mengalami kelambatan selama proses ini tetapi jelas tidak ada downtime. Percona XtraBackup akan membuat hotcopy yang lebih cepat dan lebih sedikit sumber daya dibandingkan dengan mysqldump. Ini sangat ideal untuk database InnoDB besar.

Bergantung pada pola penggunaan dan statistik, Anda dapat menjalankan proses ini ketika ada lalu lintas minimum di server. Mungkin melakukan ini selama akhir pekan adalah ide yang bagus? Di atas hanyalah garis besar dari proses. Anda mungkin perlu membaca dokumentasi Percona XtraBackup dan SSHFS.


1

Anda bisa membuang database langsung ke server jauh ...

$ mysqldump | ssh user@server 'cat - > dumpfile.sql.gz'

... SQL harus dikompres dengan baik sehingga Anda harus melakukan ini jauh lebih cepat dengan salah satu opsi ini meskipun itu akan tergantung pada jumlah RAM yang Anda miliki di dalam kotak juga ...

$ mysqldump | ssh -C user@server 'cat - > dumpfile.sql.gz'
$ mysqldump | gzip -c | ssh user@server 'cat - > dumpfile.sql.gz'
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.