anchor.diff:  There is no way to disable the WAL for only a specific table.
   
   WARNING: If you disable the WAL for anything other than bulk loads, your data is at risk.
  +
   
   [[regions.arch]]
   == Regions
  
positive.code: If writing to the WAL fails, the entire operation to modify the data fails.
  
  HBase uses an implementation of the link:https://hbase.apache.org/devapidocs/org/apache/hadoop/hbase/wal/WAL.html[WAL] interface.
  Usually, there is only one instance of a WAL per RegionServer.
  The RegionServer records Puts and Deletes to it, before recording them to the <<store.memstore>> for the affected <<store>>.
  
  .The HLog
  [NOTE]
  
negative.code: mid-write. If entries in this last block were added with new dictionary entries but we failed persist the amended
  dictionary because of an abrupt termination, a read of this last block may not be able to resolve last-written entries.
  
  [[wal.durability]]
  ==== Durability
  It is possible to set _durability_ on each Mutation or on a Table basis. Options include:
  
   * _SKIP_WAL_: Do not write Mutations to the WAL (See the next section, <<wal.disable>>).
   * _ASYNC_WAL_: Write the WAL asynchronously; do not hold-up clients waiting on the sync of their write to the filesystem but return immediately; the Mutation will be flushed to the WAL at a later time. This option currently may lose data. See HBASE-16689.
   * _SYNC_WAL_: The *default*. Each edit is sync'd to HDFS before we return success to the client.
   * _FSYNC_WAL_: Each edit is fsync'd to HDFS and the filesystem before we return success to the client.
  
  Do not confuse the _ASYNC_WAL_ option on a Mutation or Table with the _AsyncFSWAL_ writer; they are distinct
  options unfortunately closely named
  
  [[wal.disable]]
  ==== Disabling the WAL
  
  