Read replica properties

You must understand the various properties to configure to enable support for read replicas in HBase.

Table 1. HBase Read Replica Properties
Property Name Default Value Description
hbase.region.replica.replication.enabled false

The mechanism for refreshing the secondary replicas. If set to false, secondary replicas are not guaranteed to be consistent at the row level. Secondary replicas are refreshed at intervals controlled by a timer (hbase.regionserver.storefile.refresh.period), and so are guaranteed to be at most that interval of milliseconds behind the primary RegionServer. Secondary replicas read from the HFile in HDFS, and have no access to writes that have not been flushed to the HFile by the primary RegionServer.

If true, replicas are kept up-to-date using replication.

hbase.regionserver.storefile.refresh.period 0 (disabled)

The period, in milliseconds, for refreshing the store files for the secondary replicas. The default value of 0 indicates that the feature is disabled. Secondary replicas update their store files from the primary RegionServer at this interval.

If refreshes occur too often, this can create a burden for the NameNode. If refreshes occur too infrequently, secondary replicas will be less consistent with the primary RegionServer.
hbase.ipc.client.specificThreadForWriting true Whether or not to enable interruption of RPC threads at the client. This is required for region replicas with fallback RPC’s to secondary regions. The default value of true enables primary RegionServers to access data from other regions' secondary replicas.
hbase.client.primaryCallTimeout.get 10000 μs The timeout period, in microseconds, an HBase client waits for a response before the read is submitted to a secondary replica if the read request allows timeline consistency. The default value is 10000 μs. Lower values increase the number of remote procedure calls while lowering latency.
hbase.client.primaryCallTimeout.multiget 10000 μs The timeout period, in milliseconds, before an HBase client's multi-get request, such as HTable.get(List<GET>)), is submitted to a secondary replica if the multi-get request allows timeline consistency. Lower values increase the number of remote procedure calls while lowering latency.