beberapa pertanyaan tentang detail replika couchbase

Disini saya mendapatkan beberapa pertanyaan mengenai fungsi replika di couchbase, dan semoga bisa terjawab. Pertama-tama, saya ingin memberikan sedikit pemahaman saya tentang couchbase; Jika ada 10 node di cluster saya, dan saya menetapkan jumlah replika menjadi 3 di setiap keranjang (sebenarnya saya menemukan nilai maksimalnya adalah 3, dan saya tidak dapat menemukan cara lain untuk membuatnya lebih besar dari 3), lalu, apakah ini berarti setiap data dalam keranjang hanya dapat disalin ke tiga node lainnya(Saya kira ketiga node tersebut harus dipilih secara acak, tetapi dapatkah dipilih secara manual) dengan total 10 node; Selanjutnya, jika beberapa dari 10 node mengalami downtime, apakah akan menyebabkan hilangnya data?

Saya menyimpulkan pertanyaan saya sebagai berikut;

1, Nilai maksimal nomor replika di couchbase adalah 3, benar atau salah? Kalau salah kok bisa lebih besar dari 3.

2, saya kira ketiga node harus dipilih secara acak, tetapi dapatkah dipilih secara manual

3, Jika pemahaman saya benar, data akan hilang ketika kami menemukan beberapa node sedang downtime. Bagaimana kita bisa menghindari kerugian dalam kondisi seperti itu


person user3168625    schedule 22.05.2014    source sumber


Jawaban (1)


Nilai maksimal angka replika di couchbase adalah 3 benar atau salah? Kalau salah kok bisa lebih besar dari 3.

Jumlah maksimum replika yang dapat Anda miliki adalah 3, kami menjalankan produksi dengan 1 replika, namun semuanya bergantung pada seberapa besar klaster Anda dan dampak kinerjanya. Semakin banyak replika yang Anda miliki, semakin banyak komunikasi dan transfer antar node yang akan terjadi.

Jika Anda memiliki 3 replika, ini berarti setiap node memiliki data yang direplikasi ke 3 node lainnya, ini berarti Anda dapat menangani 3 kegagalan node di cluster Anda. Hal ini bisa saja terjadi namun kecil kemungkinannya, yang lebih mungkin terjadi adalah mesin mati dan kemudian Couchbase dapat secara otomatis melakukan failover dan mempromosikan replika yang disimpan di node lain untuk melayani permintaan/pembaruan.

Sistem Couchbase bagus karena ini berarti Anda dapat meningkatkan dan menurunkan skala dengan melakukan failover pada sebuah node dan penyeimbangan ulang otomatis.

Saya kira ketiga node tersebut harus dipilih secara acak, tetapi bisakah saya memilihnya secara manual?

Anda tidak dapat menentukan replika node mana yang disimpan, bahkan menurut saya merupakan hal yang hebat bahwa semua proses sharding dan replika Couchbase diambil dari tangan pengembang, semuanya merupakan proses otomatis.

Jika pemahaman saya benar, maka akan terjadi kehilangan data ketika kami menemukan beberapa node sedang downtime. Bagaimana kita bisa menghindari kehilangan data dalam kondisi seperti itu?

Seperti yang saya katakan sebelumnya, jika satu node mati maka replika akan dipromosikan, dengan 3 cadangan Anda memerlukan 3 node untuk gagal sebelum Anda menyadari sesuatu terjadi. Dalam lingkungan produksi Anda seharusnya sudah memiliki sistem peringatan untuk setiap node, baik itu New Relic, Nagios dll yang akan melaporkan jika server mati. Jika ada masalah besar dan Anda kehilangan lebih dari 4 node maka ya, Anda akan kehilangan data.

Ingatlah bahwa failover otomatis di Couchbase tidak terjadi secara instan tetapi tetap saja cukup cepat. Jika Anda memerlukan waktu henti di seluruh kluster, katakanlah untuk pemeliharaan server yang memerlukan restart atau sesuatu, maka ada kemungkinan untuk membuat simpul gagal, menghapusnya dari kluster, melakukan operasi dan tugas di dalamnya, lalu menambahkannya kembali ke dalam kluster dan menyeimbangkan kembali. Lakukan penghentian tersebut lagi untuk node sebanyak yang Anda perlukan, Saya pribadi telah melakukannya ketika saya lupa mengatur hal-hal Linux tertentu yang memerlukan restart sistem.

Secara keseluruhan, untuk menghindari kehilangan data, pantau server Anda, buat cadangan data (harian/setiap jam) di cluster Anda, dan sediakan mesin yang siap untuk kecepatan kerja Anda.

Semoga itu bisa membantu!

person scalabilitysolved    schedule 22.05.2014