Index: src/main/javadoc/org/apache/hadoop/hbase/replication/package.html =================================================================== --- src/main/javadoc/org/apache/hadoop/hbase/replication/package.html (revision 1177464) +++ src/main/javadoc/org/apache/hadoop/hbase/replication/package.html (working copy) @@ -44,7 +44,9 @@ features:
    -
  1. Master/Slave replication limited to 1 slave cluster.
  2. +
  3. Master/Slave replication.
  4. +
  5. Master/Master replication.
  6. +
  7. Cyclic replication.
  8. Replication of scoped families in user tables.
  9. Start/stop replication stream.
  10. Supports clusters of different sizes.
  11. @@ -74,6 +76,8 @@
  12. Every table that contains families that are scoped for replication should exist on every cluster with the exact same name, same for those replicated families.
  13. +
  14. For multiple slaves, Master/Master, or cyclic replication version + 0.92 or greater is needed.

@@ -113,6 +117,10 @@ scope of 1 means it's going to be. In the future, different scope can be used for routing policies. +

  • To list all configured peers run the following command in the master's + shell +
    list_peers
    (as of version 0.92) +
  • You can confirm that your setup works by looking at any region server's log Index: src/site/xdoc/replication.xml =================================================================== --- src/site/xdoc/replication.xml (revision 1177464) +++ src/site/xdoc/replication.xml (working copy) @@ -74,6 +74,10 @@ and the master cluster will do its “best effort” to balance the stream of replication on the slave clusters by relying on randomization.

    +

    + As of version 0.92 HBase supports master/master and cyclic replication as + well as replication to multiple slaves. +

    @@ -104,17 +108,23 @@

    In a separate thread, the edit is read from the log (as part of a batch) and only the KVs that are replicable are kept (that is, that they are part - of a family scoped GLOBAL in the family's schema and non-catalog so not - .META. or -ROOT-). When the buffer is filled, or the reader hits the - end of the file, the buffer is sent to a random region server on the - slave cluster. + of a family scoped GLOBAL in the family's schema, non-catalog so not + .META. or -ROOT-, and did not originate in the target slave cluster - in + case of cyclic replication).

    + The edit is then tagged with the master's cluster UUID. + When the buffer is filled, or the reader hits the end of the file, + the buffer is sent to a random region server on the slave cluster. +

    +

    Synchronously, the region server that receives the edits reads them sequentially and separates each of them into buffers, one per table. Once all edits are read, each buffer is flushed using the normal HBase client (HTables managed by a HTablePool). This is done in order to leverage parallel insertion (MultiPut). + The master's cluster UUID is retained in the edits applied at the + slave cluster in order to allow cyclic replication.

    Back in the master cluster's region server, the offset for the current @@ -394,18 +404,6 @@ queues of another dead RS, we will miss the data from the queues that weren't copied. -

  • - HBASE-2196, a master cluster can only support a single slave, some - refactoring is needed to support this. -
  • -
  • - HBASE-2195, edits are applied disregard their home cluster, it should - carry that data and check it. -
  • -
  • - HBASE-3130, the master cluster needs to be restarted if its region - servers lose their session with a slave cluster. -