anchor.diff:      of row-level consistency, even when the read requests `Consistency.TIMELINE`.
     </description>
   </property>
  +
  +<property>
  +    <name>hbase.master.hfilecleaner.ttl</name>
  +    <value>3600000</value>
  +    <description>
  +      The period (in milliseconds) to keep store files in the archive folder before deleting them from the file system.</description>
  +</property>
  +
  +<property>
  +    <name>hbase.meta.replica.count</name>
  +    <value>3</value>
  +    <description>
  +      Region replication count for the meta regions. Defaults to 1.
  +    </description>
  +</property>
  +
  +
  +<property> 
  +    <name>hbase.region.replica.storefile.refresh.memstore.multiplier</name>
  +    <value>4</value>
  +    <description>
  +      The multiplier for a “store file refresh” operation for the secondary region replica. If a region server has memory pressure, the secondary region will refresh it’s store files if the memstore size of the biggest secondary replica is bigger this many times than the memstore size of the biggest primary replica. Set this to a very big value to disable this feature (not recommended).
  +    </description>
  +</property>
  +
  +<property>
  + <name>hbase.region.replica.wait.for.primary.flush</name>
  +    <value>true</value>
  +    <description>
  +      Whether to wait for observing a full flush cycle from the primary before start serving data in a secondary. Disabling this might cause the secondary region replicas to go back in time for reads between region movements.
  +    </description>
  +</property>
   ----
   
   One thing to keep in mind also is that, region replica placement policy is only enforced by the `StochasticLoadBalancer` which is the default balancer.
  
positive.code: [source,xml]
  ----
  <property>
    <name>hbase.regionserver.storefile.refresh.period</name>
    <value>0</value>
    <description>
      The period (in milliseconds) for refreshing the store files for the secondary regions. 0 means this feature is disabled. Secondary regions sees new files (from flushes and compactions) from primary once the secondary region refreshes the list of files in the region. But too frequent refreshes might cause extra Namenode pressure. If the files cannot be refreshed for longer than HFile TTL (hbase.master.hfilecleaner.ttl) the requests are rejected. Configuring HFile TTL to a larger value is also recommended with this setting.
    </description>
  </property>
  <property>
    <name>hbase.region.replica.replication.memstore.enabled</name>
  
negative.code: ResultScanner scanner = table.getScanner(scan);
  ----
  
  You can inspect whether the results are coming from primary region or not by calling the `Result.isStale()` method:
  
  [source,java]
  ----
  