Apache HBase Replication là một cách sao chép dữ liệu từ một cụm HBase sang một cụm HBase khác và có thể ở xa. Nó hoạt động trên nguyên tắc rằng các giao dịch từ cụm ban đầu được đẩy sang một cụm khác. Trong thuật ngữ HBase, cụm thực hiện push được gọi là master và cụm nhận các giao dịch được gọi là slave. Việc đẩy các giao dịch này được thực hiện không đồng bộ và các giao dịch này được chia thành từng đợt với kích thước có thể định cấu hình (mặc định là 64MB). Chế độ không đồng bộ tạo ra chi phí tối thiểu trên bản chính và việc vận chuyển các chỉnh sửa trong một đợt làm tăng thông lượng tổng thể.
Bài đăng trên blog này thảo luận về các trường hợp sử dụng có thể xảy ra, kiến trúc cơ bản và các chế độ sao chép HBase được hỗ trợ trong CDH4 (dựa trên 0,92). Chúng ta sẽ thảo luận về cấu hình Sao chép, khởi động và khả năng chịu lỗi trong một bài đăng blog tiếp theo.
Các trường hợp sử dụng
HBase replication hỗ trợ sao chép dữ liệu qua các trung tâm dữ liệu. Điều này có thể được sử dụng cho các tình huống khôi phục thảm họa, trong đó chúng tôi có thể yêu cầu cụm nô lệ phục vụ lưu lượng truy cập thời gian thực trong trường hợp trang web chính gặp sự cố. Vì bản sao HBase không nhằm mục đích chuyển đổi dự phòng tự động, hành động chuyển từ cụm chủ sang cụm phụ để bắt đầu phục vụ lưu lượng được thực hiện bởi người dùng. Sau đó, khi cụm chính hoạt động trở lại, người ta có thể thực hiện công việc CopyTable để sao chép các delta vào cụm chính (bằng cách cung cấp dấu thời gian bắt đầu / dừng) như được mô tả trong bài đăng blog CopyTable.
Một trường hợp sử dụng sao chép khác là khi người dùng muốn chạy các công việc MapReduce tải chuyên sâu trên cụm HBase của họ; người ta có thể làm như vậy trên cụm phụ trong khi làm giảm hiệu suất một chút trên cụm chính.
Kiến trúc
Nguyên tắc cơ bản của việc sao chép HBase là phát lại tất cả các giao dịch từ master đến slave. Điều này được thực hiện bằng cách phát lại WALEdits (Ghi các mục nhập Nhật ký phía trước) trong WALs (Ghi nhật ký phía trước) từ cụm chính, như được mô tả trong phần tiếp theo. Các WALEdits này được gửi đến các máy chủ khu vực cụm nô lệ, sau khi lọc (liệu một bản chỉnh sửa cụ thể có được xác định phạm vi để nhân rộng hay không) và vận chuyển ở kích thước lô tùy chỉnh (mặc định là 64MB). Trong trường hợp WAL Reader đạt đến cuối WAL hiện tại, nó sẽ gửi bất kỳ WALEdits nào đã được đọc cho đến lúc đó. Vì đây là một chế độ sao chép không đồng bộ, cụm phụ có thể tụt hậu so với cụm chính trong một ứng dụng nặng ghi theo thứ tự vài phút.
WAL / WALEdits / Memstore
Trong HBase, tất cả các thao tác đột biến (Puts / Deletes) được ghi vào một kho lưu trữ thuộc về một vùng cụ thể và cũng được nối vào tệp nhật ký ghi trước (WAL) ở dạng WALEdit. WALEdit là một đối tượng đại diện cho một giao dịch và có thể có nhiều hoạt động đột biến. Vì HBase hỗ trợ giao dịch cấp hàng đơn, nên một WALEdit chỉ có thể có các mục nhập cho một hàng. Các WAL được lặp lại sau một khoảng thời gian đã định cấu hình (mặc định là 60 phút) để tại bất kỳ thời điểm nào, chỉ có một WAL hoạt động trên mỗi máy chủ vùng.
IncrementColumnValue, một hoạt động CAS (kiểm tra và thay thế), cũng được chuyển đổi thành Đặt khi được ghi vào WAL.
Kho lưu trữ là một bản đồ được sắp xếp trong bộ nhớ chứa các giá trị chính của khu vực sáng tác; có một kho lưu trữ cho mỗi họ cột cho mỗi vùng. Kho lưu trữ được chuyển vào đĩa dưới dạng HFile sau khi nó đạt đến kích thước đã định cấu hình (mặc định là 64MB).
Ghi vào WAL là tùy chọn, nhưng bắt buộc phải tránh mất dữ liệu vì trong trường hợp máy chủ vùng gặp sự cố, HBase có thể mất tất cả các kho lưu trữ trên máy chủ vùng đó. Trong trường hợp máy chủ vùng bị lỗi, các WAL của nó sẽ được phát lại bằng quy trình tách Nhật ký để khôi phục dữ liệu được lưu trữ trong WAL.
Để sao chép hoạt động, ghi vào WALs phải được bật.
ClusterId
Mỗi cụm HBase đều có một clusterID, một loại UUID do HBase tự động tạo ra. Nó được lưu giữ trong hệ thống tệp cơ bản (thường là HDFS) để nó không thay đổi giữa các lần khởi động lại. Điều này được lưu trữ bên trong znode / hbase / hbaseid. Id này được sử dụng để sao chép master-master / acyclic một cách nhanh chóng. WAL chứa các mục nhập cho một số vùng được lưu trữ trên máy chủ vùng. Mã sao chép đọc tất cả các giá trị khóa và lọc ra các giá trị khóa được xác định phạm vi sao chép. Nó thực hiện điều này bằng cách xem thuộc tính họ cột của giá trị khóa và khớp nó với cấu trúc dữ liệu bản đồ họ cột của WALEdit. Trong trường hợp một giá trị khóa cụ thể được xác định phạm vi sao chép, nó sẽ chỉnh sửa tham số clusterId của giá trị khóa thành Id cụm HBase.
ReplicationSource
ReplicationSource là một đối tượng java Thread trong quy trình máy chủ vùng và chịu trách nhiệm sao chép các mục WAL sang một cụm nô lệ cụ thể. Nó có một hàng đợi ưu tiên chứa các tệp nhật ký sẽ được sao chép. Ngay sau khi một nhật ký được xử lý, nó sẽ bị xóa khỏi hàng đợi. Hàng đợi ưu tiên sử dụng bộ so sánh so sánh các tệp nhật ký dựa trên dấu thời gian tạo của chúng, (được nối vào tên tệp nhật ký); vì vậy, các bản ghi được xử lý theo thứ tự như thời gian tạo của chúng (các bản ghi cũ hơn được xử lý trước). Nếu chỉ có một tệp nhật ký trong hàng đợi ưu tiên, nó sẽ không bị xóa vì nó đại diện cho WAL hiện tại.
Vai trò của Zookeeper
Zookeeper đóng một vai trò quan trọng trong HBase Replication, nơi nó quản lý / điều phối gần như tất cả các hoạt động sao chép chính, chẳng hạn như đăng ký một cụm nô lệ, bắt đầu / dừng sao chép, xếp hàng các WAL mới, xử lý chuyển đổi dự phòng máy chủ vùng, v.v. Bạn nên có một hoạt động lành mạnh Số đại biểu Zookeeper (ít nhất 3 nút trở lên) để nó luôn hoạt động. Zookeeper nên được chạy độc lập (và không phải bởi HBase). Hình sau cho thấy một mẫu cấu trúc znodes liên quan đến bản sao trong cụm chính (văn bản sau dấu hai chấm là dữ liệu của 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
Hình 1. Hệ thống phân cấp znodes sao chép
Theo Hình 1, có ba máy chủ vùng trong cụm chính, đó là foo [1-3] .bar.com. Có ba znodes liên quan đến sao chép:
- trạng thái :Znode này cho biết liệu tính năng sao chép có được kích hoạt hay không. Tất cả các bước cơ bản (chẳng hạn như xếp hàng đợi nhật ký mới được cuộn trong hàng đợi sao chép, đọc tệp nhật ký để thực hiện các lô hàng WALEdits, v.v.), hãy kiểm tra giá trị boolean này trước khi xử lý. Điều này được đặt bởi thuộc tính "hbase.replication" thành true trong hbase-conf.xml. Một cách khác để thay đổi giá trị của nó là sử dụng lệnh “start / stop replication” trong hbase shell. Điều này sẽ được thảo luận trong bài đăng blog thứ hai.
- đồng nghiệp :Znode này có các đồng nghiệp / nô lệ được kết nối khi còn nhỏ. Trong hình, có một nô lệ với peerId =1, và giá trị của nó là chuỗi kết nối (Zookeeper_quorum_of_slave:Zookeeper_client_port:root_hbase_znode), trong đó Zookeeper_quorum_of_slave là danh sách các máy chủ sở thú được phân tách bằng dấu phẩy. Tên znode peerId giống với tên đã cho khi thêm một ứng dụng ngang hàng.
- rs :Znode này chứa danh sách các máy chủ vùng đang hoạt động trong cụm chính. Mỗi znode của máy chủ vùng có một danh sách các WAL sẽ được sao chép và giá trị của các znode nhật ký này là null (trong trường hợp nhật ký chưa được mở để sao chép) hoặc độ lệch byte đến điểm mà nhật ký đã được đọc. Giá trị bù byte cho một znode WAL cho biết độ lệch byte của tệp WAL tương ứng mà nó đã được đọc và sao chép. Vì có thể có nhiều hơn một cụm nô lệ và tiến trình sao chép có thể khác nhau giữa chúng (ví dụ:một cụm có thể bị hỏng), tất cả các WAL đều được chứa trong một znode ngang hàng dưới rs. Do đó, trong hình trên, các znodes của WAL nằm dưới are / rs // 1, trong đó “1” là peerId.
Chế độ sao chép
Có ba chế độ để thiết lập HBase Replication:
- Master-Slave:Trong chế độ này, việc sao chép được thực hiện theo một hướng duy nhất, tức là các giao dịch từ một cụm được đẩy sang cụm khác. Lưu ý rằng cụm phụ cũng giống như bất kỳ cụm nào khác và có thể có các bảng, lưu lượng truy cập, v.v.
- Master-Master:Trong chế độ này, bản sao được gửi qua cả hai hướng, cho các bảng khác nhau hoặc giống nhau, tức là cả hai cụm đều hoạt động như chính và nô lệ. Trong trường hợp họ đang sao chép cùng một bảng, người ta có thể nghĩ rằng nó có thể dẫn đến một vòng lặp không bao giờ kết thúc, nhưng điều này có thể tránh được bằng cách đặt clusterId của một Đột biến (Đặt / Xóa) thành clusterId của cụm ban đầu. Hình 2 giải thích điều này bằng cách sử dụng hai cụm, đó là Mặt trời và Trái đất. Trong hình 2, chúng ta có hai khối đại diện cho hai cụm HBase. Chúng có clusterId 100 và 200 tương ứng. Mỗi cụm có một thể hiện của ReplicationSource, tương ứng với cụm nô lệ mà nó muốn sao chép; nó biết cụm # Id của cả hai cụm.
Hình 2. Mặt trời và Trái đất, hai cụm HBase
Giả sử cụm # Sun nhận được một đột biến mới và hợp lệ M trên một họ bảng và cột được xác định phạm vi sao chép trong cả hai cụm. Nó sẽ có một clusterID mặc định (0L). Bản sao Nguồn sao chép ReplicationSrc-E sẽ đặt cụm # Id của nó bằng với id người khởi tạo (100) và chuyển nó đến cụm # Earth. Khi cụm # Earth nhận được đột biến, nó sẽ phát lại và đột biến được lưu trong WAL của nó, theo quy trình bình thường. Cụm # Id của đột biến được giữ nguyên trong tệp nhật ký này tại cụm # Earth. Ví dụ nguồn sao chép tại cụm # Earth, (ReplicationSrc-S, sẽ đọc đột biến và kiểm tra # ID cụm của nó bằng slaveCluster # (100, bằng cụm # Mặt trời). Vì chúng bằng nhau nên nó sẽ bỏ qua mục nhập WALEdit này.
- Theo chu kỳ:Trong chế độ này, có hơn hai cụm HBase đang tham gia vào quá trình thiết lập sao chép và một cụm có thể có nhiều sự kết hợp có thể có của master-slave và master-master được thiết lập giữa hai cụm bất kỳ. Hai điều trên bao gồm những trường hợp tốt; một tình huống khó khăn là khi chúng ta đã thiết lập chu trình
Hình 3. Thiết lập sao chép vòng tròn
Hình 3. cho thấy một thiết lập sao chép vòng tròn, trong đó cụm # Mặt trời đang tái tạo thành cụm # Trái đất, cụm # Trái đất đang tái tạo thành cụm # Sao Kim và cụm # Sao Kim đang sao chép thành cụm # Mặt trời.
Giả sử cụm # Mặt trời nhận được một đột biến mới M và có phạm vi sao chép trên tất cả các cụm trên. Nó sẽ được sao chép sang cụm # Earth như đã giải thích ở trên trong bản sao chính tổng thể. Cá thể nguồn sao chép tại cụm # Trái đất, ReplicationSrc-V, sẽ đọc WAL và xem sự đột biến và sao chép nó vào cụm # Sao Kim. Cụm # Id của đột biến được giữ nguyên vẹn (như cụm # Mặt trời), tại cụm # Sao Kim. Tại cụm này, ví dụ nguồn sao chép cho cụm # Sun, ReplicationSrc-S, sẽ thấy rằng đột biến có cùng clusterId với slaveCluster # của nó (kể từ cụm # Sun) và do đó, bỏ qua điều này khỏi quá trình sao chép.
Kết luận
HBase Replication là chức năng mạnh mẽ có thể được sử dụng trong tình huống khôi phục sau thảm họa. Nó đã được thêm vào như một tính năng xem trước trong bản phát hành 0.90 và đã được phát triển cùng với HBase nói chung, với việc bổ sung các chức năng như sao chép tổng thể, sao chép theo chu kỳ (cả hai đều được thêm vào 0,92) và cho phép vô hiệu hóa sao chép ở cấp độ ngang hàng (được thêm vào 0,94).
Trong bài đăng blog tiếp theo, chúng ta sẽ thảo luận về các tính năng hoạt động khác nhau như Cấu hình, v.v. và các mẹo khác với HBase Replication.
