HBASE-9149 javadoc cleanup of to reflect .META. rename to hbase:meta (Misty Stanley-Jones)

This commit is contained in:
Michael Stack 2014-05-27 10:36:55 -07:00
parent bfbc6d48cd
commit aa101ca97e
9 changed files with 23 additions and 23 deletions

View File

@ -80,7 +80,7 @@ def closeTables()
end
end
# Returns true if passed region is still on 'original' when we look at .META.
# Returns true if passed region is still on 'original' when we look at hbase:meta.
def isSameServer(admin, r, original)
server = getServerNameForRegion(admin, r)
return false unless server and original
@ -94,7 +94,7 @@ class RubyAbortable
end
end
# Get servername that is up in .META.; this is hostname + port + startcode comma-delimited.
# Get servername that is up in hbase:meta; this is hostname + port + startcode comma-delimited.
# Can return nil
def getServerNameForRegion(admin, r)
return nil unless admin.isTableEnabled(r.getTableName)
@ -270,7 +270,7 @@ end
# Get configuration instance
def getConfiguration()
config = HBaseConfiguration.create()
# No prefetching on .META. This is for versions pre 0.99. Newer versions do not prefetch.
# No prefetching on hbase:meta This is for versions pre 0.99. Newer versions do not prefetch.
config.setInt("hbase.client.prefetch.limit", 1)
# Make a config that retries at short intervals many times
config.setInt("hbase.client.pause", 500)

View File

@ -125,7 +125,7 @@ while iter.hasNext
end
scanner.close
# If we're trying to see the status of all HBase tables, we need to include the
# .META. table, that is not included in our scan
# hbase:meta table, that is not included in our scan
if $tablename.nil?
meta_count += 1
end

View File

@ -88,6 +88,6 @@ log4j.logger.org.apache.hadoop.hbase.zookeeper.ZooKeeperWatcher=INFO
#log4j.logger.org.apache.hadoop.ipc.HBaseServer.trace=DEBUG
# Uncomment the below if you want to remove logging of client region caching'
# and scan of .META. messages
# and scan of hbase:meta messages
# log4j.logger.org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation=INFO
# log4j.logger.org.apache.hadoop.hbase.client.MetaScanner=INFO

View File

@ -103,7 +103,7 @@ public class DeleteTableHandler extends TableEventHandler {
waitRegionInTransition(regions);
try {
// 2. Remove table from .META. and HDFS
// 2. Remove table from hbase:meta and HDFS
removeTableData(regions);
} finally {
// 3. Update table descriptor cache
@ -127,7 +127,7 @@ public class DeleteTableHandler extends TableEventHandler {
}
/**
* Removes the table from .META. and archives the HDFS files.
* Removes the table from hbase:meta and archives the HDFS files.
*/
protected void removeTableData(final List<HRegionInfo> regions)
throws IOException, CoordinatedStateException {
@ -136,7 +136,7 @@ public class DeleteTableHandler extends TableEventHandler {
MetaEditor.deleteRegions(this.server.getCatalogTracker(), regions);
// -----------------------------------------------------------------------
// NOTE: At this point we still have data on disk, but nothing in .META.
// NOTE: At this point we still have data on disk, but nothing in hbase:meta
// if the rename below fails, hbck will report an inconsistency.
// -----------------------------------------------------------------------

View File

@ -70,7 +70,7 @@ public class TruncateTableHandler extends DeleteTableHandler {
// 1. Wait because of region in transition
waitRegionInTransition(regions);
// 2. Remove table from .META. and HDFS
// 2. Remove table from hbase:meta and HDFS
removeTableData(regions);
// -----------------------------------------------------------------------

View File

@ -1134,12 +1134,12 @@ if (!b) {
<section xml:id="arch.catalog">
<title>Catalog Tables</title>
<para>The catalog tables -ROOT- and .META. exist as HBase tables. They are filtered out
<para>The catalog table hbase:meta exists as an HBase table and is filtered out
of the HBase shell's <code>list</code> command, but they are in fact tables just like any other.
</para>
<section xml:id="arch.catalog.root">
<title>ROOT</title>
<para>-ROOT- keeps track of where the .META. table is. The -ROOT- table structure is as follows:
<para><emphasis>-ROOT- was removed in 0.96.0</emphasis> -ROOT- keeps track of where the hbase:meta table is. The -ROOT- table structure is as follows:
</para>
<para>Key:
<itemizedlist>
@ -1149,15 +1149,15 @@ if (!b) {
<para>Values:
<itemizedlist>
<listitem><para><code>info:regioninfo</code> (serialized <link xlink:href="http://hbase.apache.org/apidocs/org/apache/hadoop/hbase/HRegionInfo.html">HRegionInfo</link>
instance of .META.)</para></listitem>
<listitem><para><code>info:server</code> (server:port of the RegionServer holding .META.)</para></listitem>
<listitem><para><code>info:serverstartcode</code> (start-time of the RegionServer process holding .META.)</para></listitem>
instance of hbase:meta)</para></listitem>
<listitem><para><code>info:server</code> (server:port of the RegionServer holding hbase:meta)</para></listitem>
<listitem><para><code>info:serverstartcode</code> (start-time of the RegionServer process holding hbase:meta)</para></listitem>
</itemizedlist>
</para>
</section>
<section xml:id="arch.catalog.meta">
<title>META</title>
<para>The .META. table keeps a list of all regions in the system. The .META. table structure is as follows:
<title>hbase:meta</title>
<para>The hbase:meta table keeps a list of all regions in the system. The hbase:meta table structure is as follows:
</para>
<para>Key:
<itemizedlist>
@ -1199,7 +1199,7 @@ if (!b) {
<link xlink:href="http://hbase.apache.org/apidocs/org/apache/hadoop/hbase/client/HTable.html">HTable</link>
is responsible for finding RegionServers that are serving the
particular row range of interest. It does this by querying
the <code>.META.</code> and <code>-ROOT-</code> catalog tables
the <code>hbase:meta</code> and <code>-ROOT-</code> catalog tables
(TODO: Explain). After locating the required
region(s), the client <emphasis>directly</emphasis> contacts
the RegionServer serving that region (i.e., it does not go
@ -1542,7 +1542,7 @@ rs.close();
</para>
</section>
<section xml:id="master.processes.catalog"><title>CatalogJanitor</title>
<para>Periodically checks and cleans up the .META. table. See <xref linkend="arch.catalog.meta" /> for more information on META.</para>
<para>Periodically checks and cleans up the hbase:meta table. See <xref linkend="arch.catalog.meta" /> for more information on META.</para>
</section>
</section>
@ -1641,7 +1641,7 @@ rs.close();
<para>Your data isn't the only resident of the block cache, here are others that you may have to take into account:
</para>
<itemizedlist>
<listitem><para>Catalog tables: The -ROOT- and .META. tables are forced into the block cache and have the in-memory priority which means that they are harder to evict. The former never uses
<listitem><para>Catalog tables: The -ROOT- and hbase:meta tables are forced into the block cache and have the in-memory priority which means that they are harder to evict. The former never uses
more than a few hundreds of bytes while the latter can occupy a few MBs (depending on the number of regions).</para>
</listitem>
<listitem><para>HFiles indexes: HFile is the file format that HBase uses to store data in HDFS and it contains a multi-layered index in order seek to the data without having to read the whole file.
@ -2766,7 +2766,7 @@ major version (0.90.7 uberhbck can repair a 0.90.4). However, versions &lt;=0.90
These are generally region consistency repairs -- localized single region repairs, that only modify
in-memory data, ephemeral zookeeper data, or patch holes in the META table.
Region consistency requires that the HBase instance has the state of the regions data in HDFS
(.regioninfo files), the regions row in the .META. table., and regions deployment/assignments on
(.regioninfo files), the regions row in the hbase:meta table., and regions deployment/assignments on
region servers and the master in accordance. Options for repairing region consistency include:
<itemizedlist>
<listitem><para><code>-fixAssignments</code> (equivalent to the 0.90 <code>-fix</code> option) repairs unassigned, incorrectly

View File

@ -1362,7 +1362,7 @@ hbase> restore_snapshot 'myTableSnapshot-122112'
<section xml:id="table.rename">
<title>Table Rename</title>
<para>In versions 0.90.x of hbase and earlier, we had a simple script that would rename the hdfs
table directory and then do an edit of the .META. table replacing all mentions of the old
table directory and then do an edit of the hbase:meta table replacing all mentions of the old
table name with the new. The script was called <command>./bin/rename_table.rb</command>. The
script was deprecated and removed mostly because it was unmaintained and the operation
performed by the script was brutal. </para>

View File

@ -958,7 +958,7 @@ ERROR org.apache.hadoop.hbase.regionserver.HRegionServer: ZooKeeper session expi
<section xml:id="trouble.rs.runtime.notservingregion">
<title>NotServingRegionException</title>
<para>This exception is "normal" when found in the RegionServer logs at DEBUG level. This exception is returned back to the client
and then the client goes back to .META. to find the new location of the moved region.</para>
and then the client goes back to hbase:meta to find the new location of the moved region.</para>
<para>However, if the NotServingRegionException is logged ERROR, then the client ran out of retries and something probably wrong.</para>
</section>
<section xml:id="trouble.rs.runtime.double_listed_regions">

View File

@ -108,7 +108,7 @@
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, non-catalog so not
.META. or -ROOT-, and did not originate in the target slave cluster - in
hbase:meta or -ROOT-, and did not originate in the target slave cluster - in
case of cyclic replication).
</p>
<p>