Hbase缺省配置文件

最新推荐文章于 2024-01-19 09:26:39 发布

mmicky20110730

最新推荐文章于 2024-01-19 09:26:39 发布

阅读量1.8k

点赞数

分类专栏： Hbase

本文链接：https://blog.csdn.net/book_mmicky/article/details/25714223

版权

Hbase 专栏收录该内容

5 篇文章 0 订阅

订阅专栏

hbase在0.95之后，分别有了hadoop1和hadoop2版了。在配置hbase的配置文件的时候，由于二进制的发布版所带的配置文件是空白的，给用户带来了配置的不便；事实上，在hbase的源码包中带有缺省的配置文件，如本人使用的hbase-0.96.0-src.tar.gz解压后在hbase-0.96.0/hbase-common/src/main/resources可以找到缺省的配置文件hbase-default.xml：

<?xml version="1.0"?>

<?xml-stylesheet type="text/xsl" href="configuration.xsl"?>

<!--

/**

* Licensed to the Apache Software Foundation (ASF) under one

* or more contributor license agreements. See the NOTICE file

* distributed with this work for additional information

* regarding copyright ownership. The ASF licenses this file

* to you under the Apache License, Version 2.0 (the

* "License"); you may not use this file except in compliance

* with the License. You may obtain a copy of the License at

* http://www.apache.org/licenses/LICENSE-2.0

* Unless required by applicable law or agreed to in writing, software

* distributed under the License is distributed on an "AS IS" BASIS,

* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.

* See the License for the specific language governing permissions and

* limitations under the License.

-->

<!--

OVERVIEW

The important configs. are listed near the top. You should change

at least the setting for hbase.tmp.dir. Other settings will change

dependent on whether you are running hbase in standalone mode or

distributed. See the hbase reference guide for requirements and

guidance making configuration.

This file does not contain all possible configurations. The file would be

much larger if it carried everything. The absent configurations will only be

found through source code reading. The idea is that such configurations are

exotic and only those who would go to the trouble of reading a particular

section in the code would be knowledgeable or invested enough in ever wanting

to alter such configurations, so we do not list them here. Listing all

possible configurations would overwhelm and obscure the important.

-->

<!--Configs you will likely change are listed here at the top of the file.

-->

<name>hbase.tmp.dir</name>

<value>${java.io.tmpdir}/hbase-${user.name}</value>

<description>Temporary directory on the local filesystem.

Change this setting to point to a location more permanent

than '/tmp', the usual resolve for java.io.tmpdir, as the

'/tmp' directory is cleared on machine restart.</description>

</property>

<name>hbase.rootdir</name>

<value>${hbase.tmp.dir}/hbase</value>

<description>The directory shared by region servers and into

which HBase persists. The URL should be 'fully-qualified'

to include the filesystem scheme. For example, to specify the

HDFS directory '/hbase' where the HDFS instance's namenode is

running at namenode.example.org on port 9000, set this value to:

hdfs://namenode.example.org:9000/hbase. By default, we write

to whatever ${hbase.tmp.dir} is set too -- usually /tmp --

so change this configuration or else all data will be lost on

machine restart.</description>

</property>

<name>hbase.cluster.distributed</name>

<value>false</value>

<description>The mode the cluster will be in. Possible values are

false for standalone mode and true for distributed mode. If

false, startup will run all HBase and ZooKeeper daemons together

in the one JVM.</description>

</property>

<name>hbase.zookeeper.quorum</name>

<value>localhost</value>

<description>Comma separated list of servers in the ZooKeeper ensemble

(This config. should have been named hbase.zookeeper.ensemble).

For example, "host1.mydomain.com,host2.mydomain.com,host3.mydomain.com".

By default this is set to localhost for local and pseudo-distributed modes

of operation. For a fully-distributed setup, this should be set to a full

list of ZooKeeper ensemble servers. If HBASE_MANAGES_ZK is set in hbase-env.sh

this is the list of servers which hbase will start/stop ZooKeeper on as

part of cluster start/stop. Client-side, we will take this list of

ensemble members and put it together with the hbase.zookeeper.clientPort

config. and pass it into zookeeper constructor as the connectString

parameter.</description>

</property>

<!--The above are the important configurations for getting hbase up

and running -->

<name>hbase.local.dir</name>

<value>${hbase.tmp.dir}/local/</value>

<description>Directory on the local filesystem to be used

as a local storage.</description>

</property>

<name>hbase.master.port</name>

<description>The port the HBase Master should bind to.</description>

</property>

<name>hbase.master.info.port</name>

<description>The port for the HBase Master web UI.

Set to -1 if you do not want a UI instance run.</description>

</property>

<name>hbase.master.info.bindAddress</name>

<description>The bind address for the HBase Master web UI

</description>

</property>

<name>hbase.master.logcleaner.plugins</name>

<value>org.apache.hadoop.hbase.master.cleaner.TimeToLiveLogCleaner</value>

<description>A comma-separated list of LogCleanerDelegate invoked by

the LogsCleaner service. These WAL/HLog cleaners are called in order,

so put the HLog cleaner that prunes the most HLog files in front. To

implement your own LogCleanerDelegate, just put it in HBase's classpath

and add the fully qualified class name here. Always add the above

default log cleaners in the list.</description>

</property>

<name>hbase.master.logcleaner.ttl</name>

<description>Maximum time a HLog can stay in the .oldlogdir directory,

after which it will be cleaned by a Master thread.</description>

</property>

<name>hbase.master.hfilecleaner.plugins</name>

<value>org.apache.hadoop.hbase.master.cleaner.TimeToLiveHFileCleaner</value>

<description>A comma-separated list of HFileCleanerDelegate invoked by

the HFileCleaner service. These HFiles cleaners are called in order,

so put the cleaner that prunes the most files in front. To

implement your own HFileCleanerDelegate, just put it in HBase's classpath

and add the fully qualified class name here. Always add the above

default log cleaners in the list as they will be overwritten in

hbase-site.xml.</description>

</property>

<name>hbase.master.catalog.timeout</name>

<description>Timeout value for the Catalog Janitor from the master to

META.</description>

</property>

<name>fail.fast.expired.active.master</name>

<value>false</value>

<description>If abort immediately for the expired master without trying

to recover its zk session.</description>

</property>

<name>hbase.master.dns.interface</name>

<value>default</value>

<description>The name of the Network Interface from which a master

should report its IP address.</description>

</property>

<name>hbase.master.dns.nameserver</name>

<value>default</value>

<description>The host name or IP address of the name server (DNS)

which a master should use to determine the host name used

for communication and display purposes.</description>

</property>

<name>hbase.regionserver.port</name>

<description>The port the HBase RegionServer binds to.</description>

</property>

<name>hbase.regionserver.info.port</name>

<description>The port for the HBase RegionServer web UI

Set to -1 if you do not want the RegionServer UI to run.</description>

</property>

<name>hbase.regionserver.info.bindAddress</name>

<description>The address for the HBase RegionServer web UI</description>

</property>

<name>hbase.regionserver.info.port.auto</name>

<value>false</value>

<description>Whether or not the Master or RegionServer

UI should search for a port to bind to. Enables automatic port

search if hbase.regionserver.info.port is already in use.

Useful for testing, turned off by default.</description>

</property>

<name>hbase.regionserver.handler.count</name>

<description>Count of RPC Listener instances spun up on RegionServers.

Same property is used by the Master for count of master handlers.</description>

</property>

<name>hbase.regionserver.msginterval</name>

<description>Interval between messages from the RegionServer to Master

in milliseconds.</description>

</property>

<name>hbase.regionserver.optionallogflushinterval</name>

<description>Sync the HLog to the HDFS after this interval if it has not

accumulated enough entries to trigger a sync. Units: milliseconds.</description>

</property>

<name>hbase.regionserver.regionSplitLimit</name>

<description>Limit for the number of regions after which no more region

splitting should take place. This is not a hard limit for the number of

regions but acts as a guideline for the regionserver to stop splitting after

a certain limit. Default is MAX_INT; i.e. do not block splitting.</description>

</property>

<name>hbase.regionserver.logroll.period</name>

<description>Period at which we will roll the commit log regardless

of how many edits it has.</description>

</property>

<name>hbase.regionserver.logroll.errors.tolerated</name>

<description>The number of consecutive WAL close errors we will allow

before triggering a server abort. A setting of 0 will cause the

region server to abort if closing the current WAL writer fails during

log rolling. Even a small value (2 or 3) will allow a region server

to ride over transient HDFS errors.</description>

</property>

<name>hbase.regionserver.hlog.reader.impl</name>

<value>org.apache.hadoop.hbase.regionserver.wal.ProtobufLogReader</value>

<description>The HLog file reader implementation.</description>

</property>

<name>hbase.regionserver.hlog.writer.impl</name>

<value>org.apache.hadoop.hbase.regionserver.wal.ProtobufLogWriter</value>

<description>The HLog file writer implementation.</description>

</property>

<name>hbase.regionserver.global.memstore.upperLimit</name>

<description>Maximum size of all memstores in a region server before new

updates are blocked and flushes are forced. Defaults to 40% of heap.

Updates are blocked and flushes are forced until size of all memstores

in a region server hits hbase.regionserver.global.memstore.lowerLimit.</description>

</property>

<name>hbase.regionserver.global.memstore.lowerLimit</name>

<description>Maximum size of all memstores in a region server before

flushes are forced. Defaults to 38% of heap.

This value equal to hbase.regionserver.global.memstore.upperLimit causes

the minimum possible flushing to occur when updates are blocked due to

memstore limiting.</description>

</property>

<name>hbase.regionserver.optionalcacheflushinterval</name>

Maximum amount of time an edit lives in memory before being automatically flushed.

Default 1 hour. Set it to 0 to disable automatic flushing.</description>

</property>

<name>hbase.regionserver.catalog.timeout</name>

<description>Timeout value for the Catalog Janitor from the regionserver to META.</description>

</property>

<name>hbase.regionserver.dns.interface</name>

<value>default</value>

<description>The name of the Network Interface from which a region server

should report its IP address.</description>

</property>

<name>hbase.regionserver.dns.nameserver</name>

<value>default</value>

<description>The host name or IP address of the name server (DNS)

which a region server should use to determine the host name used by the

master for communication and display purposes.</description>

</property>

<name>zookeeper.session.timeout</name>

<description>ZooKeeper session timeout in milliseconds. It is used in two different ways.

First, this value is used in the ZK client that HBase uses to connect to the ensemble.

It is also used by HBase when it starts a ZK server and it is passed as the 'maxSessionTimeout'. See

http://hadoop.apache.org/zookeeper/docs/current/zookeeperProgrammers.html#ch_zkSessions.

For example, if a HBase region server connects to a ZK ensemble that's also managed by HBase, then the

session timeout will be the one specified by this configuration. But, a region server that connects

to an ensemble managed with a different configuration will be subjected that ensemble's maxSessionTimeout. So,

even though HBase might propose using 90 seconds, the ensemble can have a max timeout lower than this and

it will take precedence. The current default that ZK ships with is 40 seconds, which is lower than HBase's.

</description>

</property>

<name>zookeeper.znode.parent</name>

<value>/hbase</value>

<description>Root ZNode for HBase in ZooKeeper. All of HBase's ZooKeeper

files that are configured with a relative path will go under this node.

By default, all of HBase's ZooKeeper file path are configured with a

relative path, so they will all go under this directory unless changed.</description>

</property>

<name>zookeeper.znode.rootserver</name>

<value>root-region-server</value>

<description>Path to ZNode holding root region location. This is written by

the master and read by clients and region servers. If a relative path is

given, the parent folder will be ${zookeeper.znode.parent}. By default,

this means the root location is stored at /hbase/root-region-server.</description>

</property>

<name>zookeeper.znode.acl.parent</name>

<description>Root ZNode for access control lists.</description>

</property>

<name>hbase.zookeeper.dns.interface</name>

<value>default</value>

<description>The name of the Network Interface from which a ZooKeeper server

should report its IP address.</description>

</property>

<name>hbase.zookeeper.dns.nameserver</name>

<value>default</value>

<description>The host name or IP address of the name server (DNS)

which a ZooKeeper server should use to determine the host name used by the

master for communication and display purposes.</description>

</property>

<!--

The following three properties are used together to create the list of

host:peer_port:leader_port quorum servers for ZooKeeper.

-->

<name>hbase.zookeeper.peerport</name>

<description>Port used by ZooKeeper peers to talk to each other.

Seehttp://hadoop.apache.org/zookeeper/docs/r3.1.1/zookeeperStarted.html#sc_RunningReplicatedZooKeeper

for more information.</description>

</property>

<name>hbase.zookeeper.leaderport</name>

<description>Port used by ZooKeeper for leader election.

See http://hadoop.apache.org/zookeeper/docs/r3.1.1/zookeeperStarted.html#sc_RunningReplicatedZooKeeper

for more information.</description>

</property>

<name>hbase.zookeeper.useMulti</name>

<value>false</value>

<description>Instructs HBase to make use of ZooKeeper's multi-update functionality.

This allows certain ZooKeeper operations to complete more quickly and prevents some issues

with rare Replication failure scenarios (see the release note of HBASE-2611 for an example).

IMPORTANT: only set this to true if all ZooKeeper servers in the cluster are on version 3.4+

and will not be downgraded. ZooKeeper versions before 3.4 do not support multi-update and

will not fail gracefully if multi-update is invoked (see ZOOKEEPER-1495).</description>

</property>

<name>hbase.config.read.zookeeper.config</name>

<value>false</value>

Set to true to allow HBaseConfiguration to read the

zoo.cfg file for ZooKeeper properties. Switching this to true

is not recommended, since the functionality of reading ZK

properties from a zoo.cfg file has been deprecated.</description>

</property>

<!--

Beginning of properties that are directly mapped from ZooKeeper's zoo.cfg.

All properties with an "hbase.zookeeper.property." prefix are converted for

ZooKeeper's configuration. Hence, if you want to add an option from zoo.cfg,

e.g. "initLimit=10" you would append the following to your configuration:

<name>hbase.zookeeper.property.initLimit</name>

</property>

-->

<name>hbase.zookeeper.property.initLimit</name>