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.
