Replikasi Apache HBase adalah cara menyalin data dari satu cluster HBase ke cluster HBase yang berbeda dan mungkin jauh. Ini bekerja berdasarkan prinsip bahwa transaksi dari cluster asal didorong ke cluster lain. Dalam jargon HBase, cluster yang melakukan push disebut master, dan cluster yang menerima transaksi disebut slave. Dorongan transaksi ini dilakukan secara asinkron, dan transaksi ini dikelompokkan dalam ukuran yang dapat dikonfigurasi (defaultnya adalah 64 MB). Mode asinkron menimbulkan overhead minimal pada master, dan pengiriman hasil edit dalam batch meningkatkan throughput keseluruhan.
Blogpost ini membahas kemungkinan kasus penggunaan, arsitektur yang mendasari dan mode replikasi HBase seperti yang didukung dalam CDH4 (yang didasarkan pada 0,92). Kami akan membahas konfigurasi Replikasi, bootstrap, dan toleransi kesalahan dalam posting blog lanjutan.
Kasus penggunaan
Replikasi HBase mendukung replikasi data di seluruh pusat data. Ini dapat digunakan untuk skenario pemulihan bencana, di mana kita dapat meminta kluster budak melayani lalu lintas waktu nyata jika situs master sedang tidak aktif. Sejak replikasi HBase tidak dimaksudkan untuk failover otomatis, tindakan beralih dari master ke cluster budak untuk mulai melayani lalu lintas dilakukan oleh pengguna. Setelah itu, setelah master cluster aktif kembali, seseorang dapat melakukan pekerjaan CopyTable untuk menyalin delta ke master cluster (dengan memberikan cap waktu mulai/berhenti) seperti yang dijelaskan dalam posting blog CopyTable.
Kasus penggunaan replikasi lainnya adalah ketika pengguna ingin menjalankan pekerjaan MapReduce yang intensif beban di klaster HBase mereka; seseorang dapat melakukannya pada kluster budak sambil menanggung sedikit penurunan kinerja pada kluster master.
Arsitektur
Prinsip yang mendasari replikasi HBase adalah untuk memutar ulang semua transaksi dari master ke slave. Hal ini dilakukan dengan memutar ulang WALEdits (Write Ahead Log entries) di WALs (Write Ahead Log) dari master cluster, seperti yang dijelaskan di bagian berikutnya. WALEdit ini dikirim ke server wilayah klaster budak, setelah penyaringan (apakah pengeditan tertentu dicakup untuk replikasi atau tidak) dan pengiriman dalam ukuran batch yang disesuaikan (default adalah 64MB). Jika Pembaca WAL mencapai akhir WAL saat ini, ia akan mengirimkan WALEdit apa pun yang telah dibaca hingga saat itu. Karena ini adalah mode replikasi asinkron, cluster slave mungkin tertinggal dari master dalam aplikasi berat tulis dalam hitungan menit.
WAL/WALEdits/Memstore
Di HBase, semua operasi mutasi (Menempatkan/Menghapus) ditulis ke memstore yang termasuk dalam wilayah tertentu dan juga ditambahkan ke file log tulis (WAL) dalam bentuk WALEdit. WALEdit adalah objek yang mewakili satu transaksi, dan dapat memiliki lebih dari satu operasi mutasi. Karena HBase mendukung transaksi tingkat baris tunggal, satu WALEdit dapat memiliki entri hanya untuk satu baris. WAL berulang kali digulirkan setelah periode waktu yang dikonfigurasi (defaultnya adalah 60 menit) sehingga pada waktu tertentu, hanya ada satu WAL aktif per server wilayah.
IncrementColumnValue, operasi CAS (pemeriksaan dan penggantian), juga diubah menjadi Put saat ditulis ke WAL.
Memstore adalah peta yang diurutkan dalam memori yang berisi nilai kunci dari wilayah penulisan; ada satu memstore per setiap keluarga kolom per wilayah. Memstore di-flush ke disk sebagai HFile setelah mencapai ukuran yang dikonfigurasi (default adalah 64MB).
Menulis ke WAL adalah opsional, tetapi diperlukan untuk menghindari kehilangan data karena jika server wilayah mogok, HBase dapat kehilangan semua memstore yang dihosting di server wilayah tersebut. Jika terjadi kegagalan server wilayah, WAL-nya akan diputar ulang oleh proses pemisahan Log untuk memulihkan data yang disimpan dalam WAL.
Agar Replikasi berfungsi, tulis ke WAL harus diaktifkan.
Id Cluster
Setiap cluster HBase memiliki clusterID, jenis UUID yang dibuat secara otomatis oleh HBase. Itu disimpan di sistem file yang mendasarinya (biasanya HDFS) sehingga tidak berubah di antara restart. Ini disimpan di dalam /hbase/hbaseid znode. Id ini digunakan untuk mencapai replikasi master-master/asiklik. WAL berisi entri untuk sejumlah wilayah yang di-host di server wilayah. Kode replikasi membaca semua nilai kunci dan menyaring nilai kunci yang dicakup untuk replikasi. Ini dilakukan dengan melihat atribut keluarga kolom dari nilai kunci, dan mencocokkannya dengan struktur data peta keluarga kolom WALEdit. Jika nilai kunci tertentu dicakup untuk replikasi, ia mengedit parameter clusterId dari nilai kunci ke ID cluster HBase.
ReplicationSource
ReplicationSource adalah objek Java Thread dalam proses regionserver dan bertanggung jawab untuk mereplikasi entri WAL ke cluster slave tertentu. Ini memiliki antrian prioritas yang menyimpan file log yang akan direplikasi. Segera setelah log diproses, log akan dihapus dari antrian. Antrian prioritas menggunakan pembanding yang membandingkan file log berdasarkan stempel waktu pembuatannya, (yang ditambahkan ke nama file log); jadi, log diproses dalam urutan yang sama dengan waktu pembuatannya (log lama diproses terlebih dahulu). Jika hanya ada satu file log dalam antrian prioritas, file tersebut tidak akan dihapus karena mewakili WAL saat ini.
Peran Penjaga Kebun Binatang
Zookeeper memainkan peran kunci dalam Replikasi HBase, di mana ia mengelola/mengkoordinasikan hampir semua aktivitas replikasi utama, seperti mendaftarkan cluster budak, memulai/menghentikan replikasi, mengantrekan WAL baru, menangani failover regionserver, dll. Kuorum penjaga kebun binatang (setidaknya 3 atau lebih simpul) agar selalu aktif dan berjalan. Zookeeper harus dijalankan secara independen (dan bukan oleh HBase). Gambar berikut menunjukkan contoh struktur znodes terkait replikasi di master cluster (teks setelah titik dua adalah data dari znode):
/hbase/hbaseid: b53f7ec6-ed8a-4227-b088-fd6552bd6a68 …. /hbase/rs/foo1.bar.com,40020,1339435481742: /hbase/rs/foo2.bar.com,40020,1339435481973: /hbase/rs/foo3.bar.com,40020,1339435486713: /hbase/replication: /hbase/replication/state: true /hbase/replication/peers: /hbase/replication/peers/1: zk.quorum.slave:281:/hbase /hbase/replication/rs: /hbase/replication/rs/foo1.bar.com.com,40020,1339435084846: /hbase/replication/rs/foo1.bar.com,40020,1339435481973/1: /hbase/replication/rs/foo1.bar.com,40020,1339435481973/1/foo1.bar.com.1339435485769: 1243232 /hbase/replication/rs/foo3.bar.com,40020,1339435481742: /hbase/replication/rs/foo3.bar.com,40020,1339435481742/1: /hbase/replication/rs/foo3.bar.com,40020,1339435481742/1/foo3.bar..com.1339435485769: 1243232 /hbase/replication/rs/foo2.bar.com,40020,1339435089550: /hbase/replication/rs/foo2.bar.com,40020,1339435481742/1: /hbase/replication/rs/foo2.bar.com,40020,1339435481742/1/foo2.bar..com.13394354343443: 1909033
Gambar 1. Replikasi hierarki znodes
Sesuai Gambar 1, ada tiga regionserver di master cluster, yaitu foo[1-3].bar.com. Ada tiga znode yang terkait dengan replikasi:
- negara bagian :Znode ini memberitahu apakah replikasi diaktifkan atau tidak. Semua langkah mendasar (seperti apakah akan mengantrekan log yang baru digulung dalam antrian replikasi, membaca file log untuk melakukan pengiriman WALEdits, dll), periksa nilai boolean ini sebelum diproses. Ini diatur oleh pengaturan properti "hbase.replication" menjadi true di hbase-conf.xml. Cara lain untuk mengubah nilainya adalah dengan menggunakan perintah "mulai/hentikan replikasi" di shell hbase. Ini akan dibahas di posting blog kedua.
- rekan sejawat :Znode ini memiliki peer/slave yang terhubung sebagai anak-anak. Pada gambar, ada satu budak dengan peerId =1, dan nilainya adalah string koneksi (Zookeeper_quorum_of_slave:Zookeeper_client_port:root_hbase_znode), di mana Zookeeper_quorum_of_slave adalah daftar server zookeeper yang dipisahkan koma. Nama znode peerId sama dengan yang diberikan saat menambahkan peer.
- rs :Znode ini berisi daftar server wilayah aktif di master cluster. Setiap znode regionserver memiliki daftar WAL yang akan direplikasi, dan nilai znode log ini adalah null (jika log belum dibuka untuk replikasi), atau offset byte ke titik di mana log telah dibaca. Nilai offset byte untuk znode WAL menunjukkan offset byte dari file WAL terkait yang telah dibaca dan direplikasi. Karena mungkin ada lebih dari satu klaster budak, dan kemajuan replikasi dapat bervariasi di antara mereka (satu mungkin turun misalnya), semua WAL mandiri dalam znode peerId di bawah rs. Jadi, pada gambar di atas, znodes WALs berada di bawah are /rs//1, di mana “1” adalah peerId.
Mode Replikasi
Ada tiga mode untuk menyiapkan Replikasi HBase:
- Master-Slave:Dalam mode ini, replikasi dilakukan dalam satu arah, yaitu transaksi dari satu cluster didorong ke cluster lain. Perhatikan bahwa cluster slave sama seperti cluster lainnya, dan dapat memiliki tabel, traffic, dll.
- Master-Master:Dalam mode ini, replikasi dikirim di kedua arah, untuk tabel yang berbeda atau sama, yaitu, kedua cluster bertindak sebagai master dan slave. Dalam kasus bahwa mereka mereplikasi tabel yang sama, orang mungkin berpikir itu dapat menyebabkan loop yang tidak pernah berakhir, tetapi ini dihindari dengan mengatur clusterId dari Mutasi (Put/Delete) ke clusterId dari cluster asal. Gambar 2 menjelaskan hal ini dengan menggunakan dua cluster, yaitu Matahari dan Bumi. Pada gambar 2, kami memiliki dua blok yang mewakili dua cluster HBase. Mereka memiliki clusterId 100, dan 200 masing-masing. Setiap cluster memiliki instance ReplicationSource, sesuai dengan cluster slave yang ingin direplikasi; ia mengetahui kluster #Id dari kedua kluster.
Gambar 2. Matahari dan Bumi, dua gugus HBase
Katakanlah cluster#Sun menerima mutasi M yang baru dan valid pada tabel dan keluarga kolom yang dicakup untuk replikasi di kedua cluster. Ini akan memiliki clusterID default (0L). Instance Sumber replikasi ReplicationSrc-E akan menyetel cluster#Id sama dengan id originator (100), dan mengirimkannya ke cluster#Earth. Ketika cluster#Earth menerima mutasi, ia memutar ulang dan mutasi disimpan di WAL-nya, sesuai aliran normal. Cluster#Id mutasi disimpan utuh dalam file log ini di cluster#Earth. Contoh sumber Replikasi di cluster#Earth, (ReplicationSrc-S, akan membaca mutasi dan memeriksa cluster#ID dengan slaveCluster# (100, sama dengan cluster#Sun). Karena sama, entri WALEdit ini akan dilompati.
- Cyclic:Dalam mode ini, ada lebih dari dua cluster HBase yang mengambil bagian dalam pengaturan replikasi, dan seseorang dapat memiliki berbagai kemungkinan kombinasi pengaturan master-slave dan master-master di antara dua cluster mana pun. Dua di atas mencakup kasus-kasus itu dengan baik; satu situasi sudut adalah ketika kita telah menyiapkan siklus
Gambar 3. Pengaturan replikasi melingkar
Gambar 3. menunjukkan pengaturan replikasi melingkar, di mana cluster#Sun mereplikasi ke cluster#Earth, cluster#Earth mereplikasi ke cluster#Venus, dan cluster#Venus mereplikasi ke cluster#Sun.
Katakanlah cluster#Sun menerima mutasi baru M dan dicakup untuk replikasi di semua cluster di atas. Ini akan direplikasi ke cluster#Earth seperti yang dijelaskan di atas dalam master master replikasi. Instance sumber replikasi di cluster#Earth, ReplicationSrc-V, akan membaca WAL dan melihat mutasi dan mereplikasinya ke cluster#Venus. Cluster#Id mutasi tetap utuh (pada cluster#Sun), di cluster#Venus. Di cluster ini, instance sumber replikasi untuk cluster#Sun, ReplicationSrc-S, akan melihat bahwa mutasi memiliki clusterId yang sama dengan slaveCluster#-nya (pada cluster#Sun), dan oleh karena itu, abaikan ini dari replikasi.
Kesimpulan
Replikasi HBase adalah fungsionalitas yang kuat yang dapat digunakan dalam skenario pemulihan bencana. Itu ditambahkan sebagai fitur pratinjau dalam rilis 0,90, dan telah berkembang bersama dengan HBase pada umumnya, dengan penambahan fungsionalitas seperti replikasi master-master, replikasi asiklik (keduanya ditambahkan pada 0,92), dan replikasi yang memungkinkan-nonaktifkan di tingkat rekan (ditambahkan di 0.94).
Di blogpost berikutnya, kita akan membahas berbagai fitur operasional seperti Konfigurasi, dll, dan gotchas lainnya dengan Replikasi HBase.
