Kecepatan replikasi MySQL

Karena waktu Replikasi MySQL adalah variabel yang tidak dapat dikontrol (bahkan dalam implementasi yang benar, masalah dapat muncul yang menghambat replikasi, atau menghalanginya), sebaiknya jangan bergantung pada replikasi data. Anda dapat membagi masalah menjadi dua situasi:

1) Saya adalah pengguna yang melakukan operasi CUD, saya berharap kata penutup operasi R mencerminkan perubahan yang baru saja saya buat. Dalam hal ini Anda benar-benar perlu mengambil data dari master, karena pengguna mengharapkan perubahannya berdampak.

2) Saya adalah pengguna luar, saya tidak tahu apakah perintah CUD terjadi dan saya biasanya tidak peduli, jadi mengembalikan data basi dapat diterima (dalam 99% implementasi, jika tidak, Anda mungkin tidak akan menggunakan PHP* ).

Alternatif untuk #1 adalah memberi tahu pengguna bahwa perubahannya menyebar, dan dapat diterima dalam beberapa situasi, misalnya. banyak situs web akan memberi tahu Anda bahwa x mungkin memerlukan waktu hingga y menit untuk muncul, inilah situasi yang sedang terjadi.

• Jika Anda memerlukan pembaruan instan, Anda dapat mencoba menulis ke lapisan cache yang disurvei bersama dengan data DB (yang mungkin tidak dapat diandalkan). Sesuatu seperti memcached akan menjadi kandidat utama.

Itu tergantung pada seberapa cepat server SLAVE Anda mereplikasi data dari server MASTER Anda.

Jika terikat langsung dengan perintah INSERT, UPDATE, dan DELETE, artinya ketika Anda menyisipkan sesuatu, sebenarnya Anda menyisipkannya pada keduanya, kemungkinan besar akan tersedia pada keduanya.

Jika server SLAVE mereplikasi MASTER dengan tugas yang dijalankan sesering mungkin untuk mengambil data dari MASTER, yang akan lebih murah dibandingkan membuat 2 Kueri untuk setiap 1 kueri, ini berarti bahwa data tidak tersedia hingga tugas tersebut diselesaikan. berlari.