Ini adalah posting blog kedua tentang replikasi Apache HBase. Postingan blog sebelumnya, Ikhtisar Replikasi HBase, membahas kasus penggunaan, arsitektur, dan berbagai mode yang didukung dalam replikasi HBase. Blogpost ini dari perspektif operasional dan akan menyentuh konfigurasi replikasi HBase, dan konsep kunci untuk menggunakannya — seperti bootstrap, perubahan skema, dan toleransi kesalahan.
Konfigurasi
Seperti disebutkan dalam Tinjauan Replikasi HBase, cluster master mengirimkan pengiriman WALEdits ke satu atau lebih cluster budak. Bagian ini menjelaskan langkah-langkah yang diperlukan untuk mengonfigurasi replikasi dalam mode master-slave.
- Semua keluarga tabel/kolom yang akan direplikasi harus ada di kedua cluster.
- Tambahkan properti berikut di $HBASE_HOME/conf/hbase-site.xml pada semua node di kedua cluster; setel ke true.
hbase.replication
benar
Pada master cluster, buat perubahan tambahan berikut:
- Tetapkan cakupan replikasi (REPLICATION_SCOPE atribut) pada keluarga tabel/kolom yang akan direplikasi:
hbase shell> nonaktifkan 'tabel'
hbase shell> ubah 'tabel', {NAME => 'column-family', REPLICATION_SCOPE => 1}
hbase shell> aktifkan 'tabel'
REPLICATION_SCOPE adalah atribut tingkat kolom-keluarga dan nilainya dapat berupa 0 atau 1. Nilai 0 berarti replikasi dinonaktifkan, dan 1 berarti replikasi diaktifkan. Seorang pengguna harus mengubah setiap keluarga kolom dengan perintah ubah seperti yang ditunjukkan di atas, untuk semua keluarga kolom yang ingin dia tiru.
Jika pengguna ingin mengaktifkan replikasi saat membuat tabel, ia harus menggunakan perintah berikut:
hbase shell> buat 'tabel', 'column-family1', '''column-family2', {NAME => 'column-family1', REPLICATION_SCOPE => 1}
Perintah di atas akan mengaktifkan replikasi pada 'column-family1' dari tabel di atas.
2. Di shell hbase, tambahkan slave peer. Seorang pengguna seharusnya memberikan kuorum penjaga kebun binatang kluster budak, port kliennya, dan root hbase znode, bersama dengan peerId:
hbase shell>add_peer ‘peerId’, “::”
PeerId adalah string panjang satu atau dua karakter, dan znode yang sesuai dibuat di bawah rekan znode, seperti yang dijelaskan di blog sebelumnya. Setelah pengguna menjalankan perintah add_peer, kode Replikasi membuat objek ReplicationSource untuk rekan tersebut, dan semua server wilayah cluster master mencoba untuk terhubung ke server wilayah cluster budak. Itu juga mengambil ClusterId cluster budak (UUID, terdaftar di kuorum penjaga kebun binatang cluster budak). Server wilayah kluster master mencantumkan server wilayah yang tersedia dari slave dengan membaca znode “/hbase/rs” dan turunannya pada kuorum penjaga kebun kluster slave, dan membuat koneksi ke sana. Setiap regionserver di master cluster memilih subset dari slave regionservers, tergantung pada rasio yang ditentukan oleh “replication.source.ratio”, dengan nilai default 0.1. Ini berarti bahwa setiap server wilayah cluster master akan mencoba untuk terhubung ke 10% dari total server wilayah cluster budak. Saat mengirim kumpulan transaksi, server wilayah kluster master akan memilih server wilayah acak dari server wilayah yang terhubung ini. (Catatan:Replikasi tidak dilakukan untuk tabel katalog, .META. dan _ROOT_.)
Untuk menyiapkan mode master-master, langkah-langkah di atas harus diulang pada kedua cluster.
Perubahan Skema
Seperti disebutkan di bagian sebelumnya, tabel dan kolom keluarga yang direplikasi harus ada di kedua cluster. Bagian ini membahas berbagai kemungkinan skenario tentang apa yang terjadi selama perubahan skema saat replikasi masih berlangsung:
a) Hapus keluarga kolom di master:Penghapusan keluarga kolom tidak akan mempengaruhi replikasi dari setiap mutasi tertunda untuk keluarga itu. Ini karena kode replikasi membaca WAL dan memeriksa cakupan replikasi keluarga kolom untuk setiap WALEdit. Setiap WALEdit memiliki peta keluarga kolom yang memungkinkan replikasi; pemeriksaan dilakukan pada semua keluarga kolom nilai kunci yang menyusun (apakah mereka dicakup atau tidak). Jika ada di peta, itu ditambahkan ke pengiriman. Karena objek WALEdit dibuat sebelum keluarga kolom dihapus, replikasinya tidak akan terpengaruh.
b) Hapus keluarga kolom di slave:WALEdit dikirim dari master cluster ke server wilayah slave tertentu, yang memprosesnya seperti klien HBase normal (menggunakan objek HTablePool). Karena keluarga kolom dihapus, operasi put akan gagal dan pengecualian itu dilemparkan ke cluster server wilayah master.
Mulai/Hentikan Replikasi
Perintah Start/Stop berfungsi sebagai tombol pemutus. Ketika perintah stop_replication dijalankan di shell HBase, itu akan mengubah nilai /hbase/replication/state menjadi false. Ini akan menghentikan semua objek sumber replikasi dari membaca log; tetapi entri baca yang ada akan dikirimkan. Jika pengguna menggunakan perintah hentikan replikasi, log yang baru diluncurkan tidak akan diantrekan untuk replikasi. Demikian pula, mengeluarkan perintah start_replication akan memulai replikasi dari WAL saat ini (yang mungkin berisi beberapa transaksi sebelumnya), dan bukan dari saat perintah dikeluarkan.
Gambar 1 menjelaskan perilaku sakelar start-stop, di mana urutan peristiwa mengalir dalam arah panah.
Kompatibilitas Versi
Server wilayah cluster master terhubung ke server wilayah cluster budak sebagai klien HBase normal. Aturan kompatibilitas yang sama berlaku untuk apakah klien HBase pada versi xxx didukung pada server HBase pada versi yyy.
Di poin lain, karena replikasi masih berkembang (semakin banyak fungsi terus ditambahkan ke dalamnya), pengguna harus menyadari fungsi yang ada. Misalnya, di CDH4, yang didasarkan pada cabang HBase 0,92, ada dukungan untuk replikasi master-master dan siklik. Mengaktifkan/Menonaktifkan sumber replikasi di tingkat rekan ditambahkan di cabang HBase 0.94.
Boot-strapping
Replikasi bekerja dengan membaca WAL server wilayah cluster master. Jika pengguna ingin mereplikasi data lama, mereka dapat menjalankan perintah copyTable (menentukan cap waktu mulai dan berakhir), sambil mengaktifkan replikasi. Perintah copyTable akan menyalin data yang dicakup oleh cap waktu mulai/akhir, dan replikasi akan menangani data saat ini. Pendekatan keseluruhan dapat diringkas sebagai:
- Mulai replikasi (perhatikan stempel waktu).
- Jalankan perintah copyTable dengan stempel waktu akhir yang sama dengan stempel waktu di atas.
- Karena replikasi dimulai dari WAL saat ini, mungkin ada beberapa nilai kunci yang disalin ke slave oleh pekerjaan replikasi dan copyTable. Ini masih baik-baik saja, karena ini adalah operasi idempoten.
Dalam kasus replikasi master-master, seseorang harus menjalankan pekerjaan copyTable sebelum memulai replikasi. Ini karena jika pengguna memulai pekerjaan copyTable setelah mengaktifkan replikasi, master kedua akan mengirim ulang data ke master pertama, karena copyTable tidak mengedit clusterId di objek mutasi. Pendekatan keseluruhan dapat diringkas sebagai:
- Jalankan pekerjaan copyTable, (perhatikan stempel waktu mulai pekerjaan).
- Mulai replikasi.
- Jalankan copyTable lagi dengan waktu mulai sama dengan waktu mulai yang dicatat pada langkah 1.
Ini juga memerlukan beberapa data yang didorong bolak-balik antara dua cluster; tetapi meminimalkan ukurannya.
Toleransi Kesalahan
Kegagalan Server Wilayah Kluster Master
Semua server wilayah di master cluster membuat znode di bawah “/ hbase/replication/rs”, seperti yang disebutkan di bagian Arsitektur. Server wilayah menambahkan znode anak untuk setiap WAL, dengan offset byte di bawah znode-nya dalam hierarki replikasi, seperti yang ditunjukkan pada Gambar 1. Jika server wilayah gagal, server wilayah lain perlu menangani log server wilayah yang mati, yang tercantum di bawahnya znode server wilayah. Semua server wilayah mengawasi znode server wilayah lain (“/hbase/rs”) znode; jadi ketika server wilayah gagal, server wilayah lain akan mendapatkan acara sebagai master menandai server wilayah ini sebagai mati. Dalam hal ini, semua server wilayah lain berlomba untuk mentransfer WAL dari znode server wilayah mati ke znode mereka, dan melampirkan awalan dengan id budak dan nama server wilayah mati, untuk membedakan dari log normal lainnya. Sumber replikasi terpisah (instance NodeFailoverWorker) dibuat untuk log yang ditransfer, yang mati setelah memproses log yang ditransfer ini.
Jika seseorang menganggap Gambar 1 dari Tinjauan Replikasi HBase sebagai gambar dasar hierarki znodes replikasi, Gambar 2. menunjukkan hierarki znodes replikasi baru jika server foo1.bar.com mati dan foo2.bar.com mengambil alih antriannya. Perhatikan znode baru “1-foo1.bar.com,40020,1339435481973” yang dibuat di bawah foo2.bar.com znode
/hbase/hbaseid:b53f7ec6-ed8a-4227-b088-fd6552bd6a68 …. /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 /hbase/replication/rs/foo2.bar.com,40020,1339435481742/1- foo1.bar.com,40020,1339435481973 /foo1.bar.com.1339435485769:1243232
Gambar 2. Hirarki znodes failover regionserver
Sementara itu, pemisahan log dapat terjadi dan dapat mengarsipkan log server wilayah yang mati. Sumber replikasi mencari log di direktori reguler dan yang diarsipkan.
Kluster budak lambat/tidak responsif (atau server wilayah)
Saat klaster slave down, atau jika ada partisi jaringan sementara, log yang belum direplikasi ke slave tidak akan dihapus oleh pembersih log HBase.
Pembersihan log ditangani oleh kelas LogCleaner, yang terus berjalan setelah waktu yang dikonfigurasi. Kode replikasi menambahkan plugin ReplicationLogCleaner, ke kelas LogCleaner. Ketika yang terakhir mencoba untuk menghapus log tertentu, ReplicationLogCleaner akan melihat apakah log itu ada dalam hierarki znode replikasi (di bawah /hbase/replication/rs/ znode). Jika log ditemukan, berarti log tersebut belum direplikasi, dan akan melewati penghapusannya. Setelah log direplikasi, znode-nya akan dihapus dari hierarki replikasi. Dalam proses berikutnya, LogCleaner akan berhasil menghapus file log setelah direplikasi.
Verifikasi
Untuk jumlah data yang lebih kecil, seseorang dapat dengan mudah mencari baris tabel menggunakan shell hbase di cluster budak untuk memverifikasi apakah mereka direplikasi atau tidak. Cara standar untuk memverifikasi adalah dengan menjalankan tugas verifikasirep mapreduce, yang disertakan dengan HBase. Itu harus dijalankan di master cluster dan membutuhkan slave clusterId dan nama tabel target. Seseorang juga dapat memberikan argumen tambahan seperti stempel waktu mulai/berhenti dan keluarga kolom. Ini mencetak dua penghitung yaitu, GOODROWS dan BADROWS, masing-masing menandakan jumlah baris yang direplikasi dan tidak direplikasi.
Metrik Replikasi
Kerangka kerja replikasi memperlihatkan beberapa metrik berguna yang dapat digunakan untuk memeriksa kemajuan replikasi. Beberapa yang penting adalah:
- sizeOfLogQueue:jumlah HLog yang akan diproses (tidak termasuk yang sedang diproses) di sumber Replikasi
- shippedOpsRate:tingkat mutasi yang dikirimkan
- logEditsReadRate:laju mutasi yang dibaca dari HLog di sumber replikasi
- ageOfLastShippedOp:usia batch terakhir yang dikirimkan oleh sumber replikasi
Pekerjaan Masa Depan
Dengan semua fitur saat ini yang ada dalam replikasi HBase saat ini, masih ada ruang untuk peningkatan lebih lanjut. Ini bervariasi dari kinerja seperti mengurangi jeda waktu replikasi antara master dan slave, hingga penanganan kegagalan server wilayah yang lebih kuat (HBase-2611). Area peningkatan lebih lanjut termasuk memungkinkan replikasi tabel tingkat rekan dan penanganan yang tepat dari IncrementColumnValue (HBase-2804).
Kesimpulan
Posting ini membahas replikasi HBase dari sudut pandang operator termasuk konfigurasi (dari berbagai mode), bootstrap cluster yang ada, efek perubahan skema dan toleransi kesalahan.
