Ketersediaan tinggi MySQL, failover, dan replikasi dengan Latency


8

Kami sedang dalam proses mengimplementasikan CMS baru (Drupal 6.x) yang berjalan di MySQL. Kami memiliki dua pusat data - primer dan sekunder - dengan latensi yang diketahui di antaranya. Kami tidak yakin versi MySQL mana yang akan kami jalankan ... baik Komunitas atau Perusahaan, tetapi itu adalah TBD. Sepertinya kita akan menjalankan mesin InnoDB, OS akan menjadi RedHat EL 5.5 Server utama akan aktif, sedangkan yang sekunder akan pasif atau panas stand-bys.

Saya ingin menerapkan replikasi, ketersediaan tinggi, dan failover otomatis di MySQL di dua pusat data.

Setelah failover ke server sekunder, ketika kami gagal kembali ke server primer, kami ingin data disinkronkan dari DB sekunder ke DB primer dengan cepat dan lengkap sehingga kami dapat terus menyajikan konten dari server primer.

Saya tertarik mengetahui teknologi / alat / praktik terbaik apa yang dapat digunakan untuk menyelesaikan / mengatasi masalah ini. Juga, setiap momen gotcha atau ah-ha akan sangat dihargai juga. Saya sudah membaca tentang replikasi MySQL, clustering, dan di beberapa alat pihak ke-3 seperti Tungsten dan Dolphinics, tapi saya tidak yakin apa tindakan terbaik.

Terima kasih atas waktu Anda!

KM

Jawaban:


3

Demi kesederhanaan, saya sarankan hanya MySQL Circular Replication. Inilah alasannya:

Ada banyak teknologi dan topologi yang jauh lebih unggul daripada Replika MySQL Circular. Favorit saya, tangan ke bawah, adalah DRBD (Distributed Replicated Block Device) . Namun, DRBD berfungsi dengan baik ketika Server Pair berada di bulding, pusat data, dan rak yang sama. Lebih baik lagi bila menggunakan kabel crossover di subnet 192.168.xx antara DRBD Primary dan DRBD Secondary. Sayangnya , DRBD memiliki kinerja yang mengerikan pada jarak antara dua lokasi, meskipun DRBD masih dapat bekerja. Tidak ada topologi jaringan di sekitar untuk memberi Anda kinerja DRBD yang memuaskan yang dibutuhkan antara dua pusat data.

Setelah Anda mengatur MySQL Circular Replication antara dua server DB di dua pusat data yang berbeda, satu-satunya penyetelan yang diperlukan adalah untuk jaringan. Pada dasarnya, kinerja replikasi adalah fungsi pengaturan jaringan (kecepatan / latensi transmisi log biner di MySQL Replication Setup) dan disk I / O (DRBD).

Alternatif yang Anda inginkan untuk redundansi yang lebih baik adalah yang berikut ini sebagai contoh:

Siapkan Pasangan DRBD di kedua lokasi
Pasangan DRBD di Situs # 1 dengan VIP 111.111.111.111
Pasangan DRBD di Situs # 2 dengan VIP 222.222.222.222

Siapkan Replikasi Sirkular MySQL antara Server Utama DRBD dalam kondisi berikut:
Untuk situs # 1, gunakan 222.222.222.222 sebagai Master_Host di MySQL
Untuk situs # 2, gunakan 111.111.111.111 sebagai Master_Host di MySQL

Meskipun memperkenalkan tingkat kerumitan, sekarang Anda memiliki dua tingkat redundansi: DRBD dalam setiap situs dan Replikasi Sirkular MySQL antar situs. Anda memiliki manfaat tambahan menjalankan cadangan melalui mysqldump di DRBD Primary dari server siaga panas.

Adapun failover, DRBD menyediakan failover otomatis di salah satu situs.

Hanya jika pusat data benar-benar tidak dapat digunakan, Anda akan menggunakan DB VIP di situs siaga panas.

MEMPERBARUI

Saya baru saja melakukan pengambilan ganda dan memperhatikan bahwa Anda menggunakan Drupal6. Saya senang Anda akan mengkonversi semua tabel drupal ke InnoDB. Ini akan menghapus segala kemungkinan pembaruan tabel MyISAM yang menyebabkan kunci tabel membekukan Koneksi DB yang hanya membaca tabel MyISAM. Setiap pembaruan DML (INSERT, PEMBARUAN, HAPUS) terhadap tabel MyISAM AKAN SELALU AKAN MELAKUKAN KUNCI PENUH TABEL !!! Menggunakan InnoDB akan memperkenalkan penguncian tingkat baris, yang menghilangkan kunci tabel penuh.

Selain itu, DRBD menjadi teman Anda ketika semuanya InnoDB karena pemulihan kerusakan akan konsisten di antara Pasangan DRBD. Contrawise, DRBD dengan MyISAM tidak memberi Anda apa-apa karena tabel MyISAM yang jatuh pada DRBD Primary hanya diduplikasi ke DRBD Sekunder seperti, Anda dapat menebaknya , tabel MyISAM yang mogok.

PEMBARUAN # 2

Anda harus menggunakan dua level redundansi

Level 1: Di setiap pusat basis data, gunakan DRBD.
http://dev.mysql.com/doc/refman/5.1/en/ha-drbd.html

Menyiapkan sepasang
Startup DB Server DRBD
Startup MySQL di DRBD Primary

Ini menciptakan data yang berlebihan di tingkat disk.

Level 2: Anda harus menyiapkan MySQL Circular Replication antara
DRBD Primary DataCenter # 1 dan DRBD Primary DataCenter # 2

Setiap DRBD Primer akan menjalankan MySQL dan akan bertindak
sebagai Master dan Slave

Saya memiliki pengaturan untuk topologi klien seperti ini dan saya menganggapnya cukup stabil.


Terima kasih @Rando_MySQLDBA Maksud Anda tentang menggunakan VIP seimbang untuk pemadaman data center masuk akal. Jadi kita akan memiliki Master-Slave di setiap pusat data, kan? Jika terjadi kegagalan, apa yang menurut Anda merupakan cara terbaik untuk memastikan bahwa DB primer mutakhir? Juga, saya telah melihat replikasi melingkar, dan sepertinya itu didasarkan pada MySQL clustering? dengan NDB? Saya tidak berpikir Drupal 6 berfungsi dengan baik dengan NDB ( drupal.org/node/391130 ). Sekali lagi terima kasih atas waktunya!
KM.

Saya telah memperbarui jawaban saya !!! BTW Saya tidak pernah menyebut NDB. Replikasi Sirkular MySQL hanyalah Master-Slave yang diterapkan dua arah.
RolandoMySQLDBA

Terimakasih atas klarifikasinya. Beberapa referensi replikasi melingkar MySQL menyebutkan NDB jadi saya ingin mengecek (-: BTW, Bagaimana otomatis bisa Anda dapatkan dengan failover menggunakan topologi ini?
KM.

DRBD dirancang untuk memfasilitasi kegagalan otomatis menggunakan Linux HeartBeat atau ucarp ( ucarp.org/project/ucarp ). Perusahaan saya, LogicWorks, adalah toko ucarp. ucarp memungkinkan dua mesin untuk berbagi satu alamat IP virtual (VIP). DRBD Master akan membuat VIP dengan MySQL berjalan di atasnya. DRBD Secondary akan menjalankan ucarp dan menunggu rasio waktu mati untuk memicu failover otomatis. Skrip naik dan turun untuk ucarp untuk mengasumsikan DB VIP harus mencakup pemasangan disk DRBD, menjadikannya Utama, dan memulai MySQL. Down script akan menghentikan MySQL unmount DRBD, go Secondary dan membunuh VIP.
RolandoMySQLDBA
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.