HBASE-20072 remove 1.1 release line from the prerequisite tables.
[hbase.git] / src / main / asciidoc / _chapters / configuration.adoc
1 ////
2 /**
3  *
4  * Licensed to the Apache Software Foundation (ASF) under one
5  * or more contributor license agreements.  See the NOTICE file
6  * distributed with this work for additional information
7  * regarding copyright ownership.  The ASF licenses this file
8  * to you under the Apache License, Version 2.0 (the
9  * "License"); you may not use this file except in compliance
10  * with the License.  You may obtain a copy of the License at
11  *
12  *     http://www.apache.org/licenses/LICENSE-2.0
13  *
14  * Unless required by applicable law or agreed to in writing, software
15  * distributed under the License is distributed on an "AS IS" BASIS,
16  * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
17  * See the License for the specific language governing permissions and
18  * limitations under the License.
19  */
20 ////
21
22 [[configuration]]
23 = Apache HBase Configuration
24 :doctype: book
25 :numbered:
26 :toc: left
27 :icons: font
28 :experimental:
29
30 This chapter expands upon the <<getting_started>> chapter to further explain configuration of Apache HBase.
31 Please read this chapter carefully, especially the <<basic.prerequisites,Basic Prerequisites>>
32 to ensure that your HBase testing and deployment goes smoothly, and prevent data loss.
33 Familiarize yourself with <<hbase_supported_tested_definitions>> as well.
34
35 == Configuration Files
36 Apache HBase uses the same configuration system as Apache Hadoop.
37 All configuration files are located in the _conf/_ directory, which needs to be kept in sync for each node on your cluster.
38
39 .HBase Configuration File Descriptions
40 _backup-masters_::
41   Not present by default.
42   A plain-text file which lists hosts on which the Master should start a backup Master process, one host per line.
43
44 _hadoop-metrics2-hbase.properties_::
45   Used to connect HBase Hadoop's Metrics2 framework.
46   See the link:https://wiki.apache.org/hadoop/HADOOP-6728-MetricsV2[Hadoop Wiki entry] for more information on Metrics2.
47   Contains only commented-out examples by default.
48
49 _hbase-env.cmd_ and _hbase-env.sh_::
50   Script for Windows and Linux / Unix environments to set up the working environment for HBase, including the location of Java, Java options, and other environment variables.
51   The file contains many commented-out examples to provide guidance.
52
53 _hbase-policy.xml_::
54   The default policy configuration file used by RPC servers to make authorization decisions on client requests.
55   Only used if HBase <<security,security>> is enabled.
56
57 _hbase-site.xml_::
58   The main HBase configuration file.
59   This file specifies configuration options which override HBase's default configuration.
60   You can view (but do not edit) the default configuration file at _docs/hbase-default.xml_.
61   You can also view the entire effective configuration for your cluster (defaults and overrides) in the [label]#HBase Configuration# tab of the HBase Web UI.
62
63 _log4j.properties_::
64   Configuration file for HBase logging via `log4j`.
65
66 _regionservers_::
67   A plain-text file containing a list of hosts which should run a RegionServer in your HBase cluster.
68   By default this file contains the single entry `localhost`.
69   It should contain a list of hostnames or IP addresses, one per line, and should only contain `localhost` if each node in your cluster will run a RegionServer on its `localhost` interface.
70
71 .Checking XML Validity
72 [TIP]
73 ====
74 When you edit XML, it is a good idea to use an XML-aware editor to be sure that your syntax is correct and your XML is well-formed.
75 You can also use the `xmllint` utility to check that your XML is well-formed.
76 By default, `xmllint` re-flows and prints the XML to standard output.
77 To check for well-formedness and only print output if errors exist, use the command `xmllint -noout filename.xml`.
78 ====
79 .Keep Configuration In Sync Across the Cluster
80 [WARNING]
81 ====
82 When running in distributed mode, after you make an edit to an HBase configuration, make sure you copy the contents of the _conf/_ directory to all nodes of the cluster.
83 HBase will not do this for you.
84 Use `rsync`, `scp`, or another secure mechanism for copying the configuration files to your nodes.
85 For most configurations, a restart is needed for servers to pick up changes. Dynamic configuration is an exception to this, to be described later below.
86 ====
87
88 [[basic.prerequisites]]
89 == Basic Prerequisites
90
91 This section lists required services and some required system configuration.
92
93 [[java]]
94 .Java
95 [cols="1,1,4", options="header"]
96 |===
97 |HBase Version
98 |JDK 7
99 |JDK 8
100
101 |2.0
102 |link:http://search-hadoop.com/m/YGbbsPxZ723m3as[Not Supported]
103 |yes
104
105 |1.3
106 |yes
107 |yes
108
109
110 |1.2
111 |yes
112 |yes
113
114 |===
115
116 NOTE: HBase will neither build nor compile with Java 6.
117
118 NOTE: You must set `JAVA_HOME` on each node of your cluster. _hbase-env.sh_ provides a handy mechanism to do this.
119
120 [[os]]
121 .Operating System Utilities
122 ssh::
123   HBase uses the Secure Shell (ssh) command and utilities extensively to communicate between cluster nodes. Each server in the cluster must be running `ssh` so that the Hadoop and HBase daemons can be managed. You must be able to connect to all nodes via SSH, including the local node, from the Master as well as any backup Master, using a shared key rather than a password. You can see the basic methodology for such a set-up in Linux or Unix systems at "<<passwordless.ssh.quickstart>>". If your cluster nodes use OS X, see the section, link:https://wiki.apache.org/hadoop/Running_Hadoop_On_OS_X_10.5_64-bit_%28Single-Node_Cluster%29[SSH: Setting up Remote Desktop and Enabling Self-Login] on the Hadoop wiki.
124
125 DNS::
126   HBase uses the local hostname to self-report its IP address. Both forward and reverse DNS resolving must work in versions of HBase previous to 0.92.0. The link:https://github.com/sujee/hadoop-dns-checker[hadoop-dns-checker] tool can be used to verify DNS is working correctly on the cluster. The project `README` file provides detailed instructions on usage.
127
128 Loopback IP::
129   Prior to hbase-0.96.0, HBase only used the IP address `127.0.0.1` to refer to `localhost`, and this was not configurable.
130   See <<loopback.ip,Loopback IP>> for more details.
131
132 NTP::
133   The clocks on cluster nodes should be synchronized. A small amount of variation is acceptable, but larger amounts of skew can cause erratic and unexpected behavior. Time synchronization is one of the first things to check if you see unexplained problems in your cluster. It is recommended that you run a Network Time Protocol (NTP) service, or another time-synchronization mechanism on your cluster and that all nodes look to the same service for time synchronization. See the link:http://www.tldp.org/LDP/sag/html/basic-ntp-config.html[Basic NTP Configuration] at [citetitle]_The Linux Documentation Project (TLDP)_ to set up NTP.
134
135 [[ulimit]]
136 Limits on Number of Files and Processes (ulimit)::
137   Apache HBase is a database. It requires the ability to open a large number of files at once. Many Linux distributions limit the number of files a single user is allowed to open to `1024` (or `256` on older versions of OS X). You can check this limit on your servers by running the command `ulimit -n` when logged in as the user which runs HBase. See <<trouble.rs.runtime.filehandles,the Troubleshooting section>> for some of the problems you may experience if the limit is too low. You may also notice errors such as the following:
138 +
139 ----
140 2010-04-06 03:04:37,542 INFO org.apache.hadoop.hdfs.DFSClient: Exception increateBlockOutputStream java.io.EOFException
141 2010-04-06 03:04:37,542 INFO org.apache.hadoop.hdfs.DFSClient: Abandoning block blk_-6935524980745310745_1391901
142 ----
143 +
144 It is recommended to raise the ulimit to at least 10,000, but more likely 10,240, because the value is usually expressed in multiples of 1024. Each ColumnFamily has at least one StoreFile, and possibly more than six StoreFiles if the region is under load. The number of open files required depends upon the number of ColumnFamilies and the number of regions. The following is a rough formula for calculating the potential number of open files on a RegionServer.
145 +
146 .Calculate the Potential Number of Open Files
147 ----
148 (StoreFiles per ColumnFamily) x (regions per RegionServer)
149 ----
150 +
151 For example, assuming that a schema had 3 ColumnFamilies per region with an average of 3 StoreFiles per ColumnFamily, and there are 100 regions per RegionServer, the JVM will open `3 * 3 * 100 = 900` file descriptors, not counting open JAR files, configuration files, and others. Opening a file does not take many resources, and the risk of allowing a user to open too many files is minimal.
152 +
153 Another related setting is the number of processes a user is allowed to run at once. In Linux and Unix, the number of processes is set using the `ulimit -u` command. This should not be confused with the `nproc` command, which controls the number of CPUs available to a given user. Under load, a `ulimit -u` that is too low can cause OutOfMemoryError exceptions. See Jack Levin's major HDFS issues thread on the hbase-users mailing list, from 2011.
154 +
155 Configuring the maximum number of file descriptors and processes for the user who is running the HBase process is an operating system configuration, rather than an HBase configuration. It is also important to be sure that the settings are changed for the user that actually runs HBase. To see which user started HBase, and that user's ulimit configuration, look at the first line of the HBase log for that instance. A useful read setting config on your hadoop cluster is Aaron Kimball's Configuration Parameters: What can you just ignore?
156 +
157 .`ulimit` Settings on Ubuntu
158 ====
159 To configure ulimit settings on Ubuntu, edit _/etc/security/limits.conf_, which is a space-delimited file with four columns. Refer to the man page for _limits.conf_ for details about the format of this file. In the following example, the first line sets both soft and hard limits for the number of open files (nofile) to 32768 for the operating system user with the username hadoop. The second line sets the number of processes to 32000 for the same user.
160 ----
161 hadoop  -       nofile  32768
162 hadoop  -       nproc   32000
163 ----
164 The settings are only applied if the Pluggable Authentication Module (PAM) environment is directed to use them. To configure PAM to use these limits, be sure that the _/etc/pam.d/common-session_ file contains the following line:
165 ----
166 session required  pam_limits.so
167 ----
168 ====
169
170 Linux Shell::
171   All of the shell scripts that come with HBase rely on the link:http://www.gnu.org/software/bash[GNU Bash] shell.
172
173 Windows::
174   Prior to HBase 0.96, running HBase on Microsoft Windows was limited only for testing purposes.
175   Running production systems on Windows machines is not recommended.
176
177
178 [[hadoop]]
179 === link:https://hadoop.apache.org[Hadoop](((Hadoop)))
180
181 The following table summarizes the versions of Hadoop supported with each version of HBase.
182 Based on the version of HBase, you should select the most appropriate version of Hadoop.
183 You can use Apache Hadoop, or a vendor's distribution of Hadoop.
184 No distinction is made here.
185 See link:https://wiki.apache.org/hadoop/Distributions%20and%20Commercial%20Support[the Hadoop wiki] for information about vendors of Hadoop.
186
187 .Hadoop 2.x is recommended.
188 [TIP]
189 ====
190 Hadoop 2.x is faster and includes features, such as short-circuit reads, which will help improve your HBase random read profile.
191 Hadoop 2.x also includes important bug fixes that will improve your overall HBase experience. HBase does not support running with
192 earlier versions of Hadoop. See the table below for requirements specific to different HBase versions.
193
194 Hadoop 3.x is still in early access releases and has not yet been sufficiently tested by the HBase community for production use cases.
195 ====
196
197 Use the following legend to interpret this table:
198
199 .Hadoop version support matrix
200
201 * "S" = supported
202 * "X" = not supported
203 * "NT" = Not tested
204
205 [cols="1,1,1,1", options="header"]
206 |===
207 | | HBase-1.2.x | HBase-1.3.x | HBase-2.0.x
208 |Hadoop-2.0.x-alpha | X | X | X
209 |Hadoop-2.1.0-beta | X | X | X
210 |Hadoop-2.2.0 | X  | X | X
211 |Hadoop-2.3.x | X  | X | X
212 |Hadoop-2.4.x | S | S | X
213 |Hadoop-2.5.x | S | S | X
214 |Hadoop-2.6.0 | X | X | X
215 |Hadoop-2.6.1+ | S | S | S
216 |Hadoop-2.7.0 | X | X | X
217 |Hadoop-2.7.1+ | S | S | S
218 |Hadoop-2.8.0 | X | X | X
219 |Hadoop-2.8.1 | X | X | X
220 |Hadoop-3.0.0 | NT | NT | NT
221 |===
222
223 .Hadoop Pre-2.6.1 and JDK 1.8 Kerberos
224 [TIP]
225 ====
226 When using pre-2.6.1 Hadoop versions and JDK 1.8 in a Kerberos environment, HBase server can fail
227 and abort due to Kerberos keytab relogin error. Late version of JDK 1.7 (1.7.0_80) has the problem too.
228 Refer to link:https://issues.apache.org/jira/browse/HADOOP-10786[HADOOP-10786] for additional details.
229 Consider upgrading to Hadoop 2.6.1+ in this case.
230 ====
231
232 .Hadoop 2.6.x
233 [TIP]
234 ====
235 Hadoop distributions based on the 2.6.x line *must* have
236 link:https://issues.apache.org/jira/browse/HADOOP-11710[HADOOP-11710] applied if you plan to run
237 HBase on top of an HDFS Encryption Zone. Failure to do so will result in cluster failure and
238 data loss. This patch is present in Apache Hadoop releases 2.6.1+.
239 ====
240
241 .Hadoop 2.7.x
242 [TIP]
243 ====
244 Hadoop version 2.7.0 is not tested or supported as the Hadoop PMC has explicitly labeled that release as not being stable. (reference the link:https://s.apache.org/hadoop-2.7.0-announcement[announcement of Apache Hadoop 2.7.0].)
245 ====
246
247 .Hadoop 2.8.x
248 [TIP]
249 ====
250 Hadoop version 2.8.0 and 2.8.1 are not tested or supported as the Hadoop PMC has explicitly labeled that releases as not being stable. (reference the link:https://s.apache.org/hadoop-2.8.0-announcement[announcement of Apache Hadoop 2.8.0] and link:https://s.apache.org/hadoop-2.8.1-announcement[announcement of Apache Hadoop 2.8.1].)
251 ====
252
253 .Replace the Hadoop Bundled With HBase!
254 [NOTE]
255 ====
256 Because HBase depends on Hadoop, it bundles an instance of the Hadoop jar under its _lib_ directory.
257 The bundled jar is ONLY for use in standalone mode.
258 In distributed mode, it is _critical_ that the version of Hadoop that is out on your cluster match what is under HBase.
259 Replace the hadoop jar found in the HBase lib directory with the hadoop jar you are running on your cluster to avoid version mismatch issues.
260 Make sure you replace the jar in HBase across your whole cluster.
261 Hadoop version mismatch issues have various manifestations but often all look like its hung.
262 ====
263
264 [[dfs.datanode.max.transfer.threads]]
265 ==== `dfs.datanode.max.transfer.threads` (((dfs.datanode.max.transfer.threads)))
266
267 An HDFS DataNode has an upper bound on the number of files that it will serve at any one time.
268 Before doing any loading, make sure you have configured Hadoop's _conf/hdfs-site.xml_, setting the `dfs.datanode.max.transfer.threads` value to at least the following:
269
270 [source,xml]
271 ----
272
273 <property>
274   <name>dfs.datanode.max.transfer.threads</name>
275   <value>4096</value>
276 </property>
277 ----
278
279 Be sure to restart your HDFS after making the above configuration.
280
281 Not having this configuration in place makes for strange-looking failures.
282 One manifestation is a complaint about missing blocks.
283 For example:
284
285 ----
286 10/12/08 20:10:31 INFO hdfs.DFSClient: Could not obtain block
287           blk_XXXXXXXXXXXXXXXXXXXXXX_YYYYYYYY from any node: java.io.IOException: No live nodes
288           contain current block. Will get new block locations from namenode and retry...
289 ----
290
291 See also <<casestudies.max.transfer.threads,casestudies.max.transfer.threads>> and note that this property was previously known as `dfs.datanode.max.xcievers` (e.g. link:http://ccgtech.blogspot.com/2010/02/hadoop-hdfs-deceived-by-xciever.html[Hadoop HDFS: Deceived by Xciever]).
292
293 [[zookeeper.requirements]]
294 === ZooKeeper Requirements
295
296 ZooKeeper 3.4.x is required.
297 HBase makes use of the `multi` functionality that is only available since Zookeeper 3.4.0. The `hbase.zookeeper.useMulti` configuration property defaults to `true`.
298 Refer to link:https://issues.apache.org/jira/browse/HBASE-12241[HBASE-12241 (The crash of regionServer when taking deadserver's replication queue breaks replication)] and link:https://issues.apache.org/jira/browse/HBASE-6775[HBASE-6775 (Use ZK.multi when available for HBASE-6710 0.92/0.94 compatibility fix)] for background.
299 The property is deprecated and useMulti is always enabled in HBase 2.0.
300
301 [[standalone_dist]]
302 == HBase run modes: Standalone and Distributed
303
304 HBase has two run modes: <<standalone,standalone>> and <<distributed,distributed>>.
305 Out of the box, HBase runs in standalone mode.
306 Whatever your mode, you will need to configure HBase by editing files in the HBase _conf_ directory.
307 At a minimum, you must edit [code]+conf/hbase-env.sh+ to tell HBase which +java+ to use.
308 In this file you set HBase environment variables such as the heapsize and other options for the `JVM`, the preferred location for log files, etc.
309 Set [var]+JAVA_HOME+ to point at the root of your +java+ install.
310
311 [[standalone]]
312 === Standalone HBase
313
314 This is the default mode.
315 Standalone mode is what is described in the <<quickstart,quickstart>> section.
316 In standalone mode, HBase does not use HDFS -- it uses the local filesystem instead -- and it runs all HBase daemons and a local ZooKeeper all up in the same JVM.
317 ZooKeeper binds to a well known port so clients may talk to HBase.
318
319 [[standalone.over.hdfs]]
320 ==== Standalone HBase over HDFS
321 A sometimes useful variation on standalone hbase has all daemons running inside the
322 one JVM but rather than persist to the local filesystem, instead
323 they persist to an HDFS instance.
324
325 You might consider this profile when you are intent on
326 a simple deploy profile, the loading is light, but the
327 data must persist across node comings and goings. Writing to
328 HDFS where data is replicated ensures the latter.
329
330 To configure this standalone variant, edit your _hbase-site.xml_
331 setting _hbase.rootdir_  to point at a directory in your
332 HDFS instance but then set _hbase.cluster.distributed_
333 to _false_. For example:
334
335 [source,xml]
336 ----
337 <configuration>
338   <property>
339     <name>hbase.rootdir</name>
340     <value>hdfs://namenode.example.org:8020/hbase</value>
341   </property>
342   <property>
343     <name>hbase.cluster.distributed</name>
344     <value>false</value>
345   </property>
346 </configuration>
347 ----
348
349 [[distributed]]
350 === Distributed
351
352 Distributed mode can be subdivided into distributed but all daemons run on a single node -- a.k.a. _pseudo-distributed_ -- and _fully-distributed_ where the daemons are spread across all nodes in the cluster.
353 The _pseudo-distributed_ vs. _fully-distributed_ nomenclature comes from Hadoop.
354
355 Pseudo-distributed mode can run against the local filesystem or it can run against an instance of the _Hadoop Distributed File System_ (HDFS). Fully-distributed mode can ONLY run on HDFS.
356 See the Hadoop link:https://hadoop.apache.org/docs/current/[documentation] for how to set up HDFS.
357 A good walk-through for setting up HDFS on Hadoop 2 can be found at http://www.alexjf.net/blog/distributed-systems/hadoop-yarn-installation-definitive-guide.
358
359 [[pseudo]]
360 ==== Pseudo-distributed
361
362 .Pseudo-Distributed Quickstart
363 [NOTE]
364 ====
365 A quickstart has been added to the <<quickstart,quickstart>> chapter.
366 See <<quickstart_pseudo,quickstart-pseudo>>.
367 Some of the information that was originally in this section has been moved there.
368 ====
369
370 A pseudo-distributed mode is simply a fully-distributed mode run on a single host.
371 Use this HBase configuration for testing and prototyping purposes only.
372 Do not use this configuration for production or for performance evaluation.
373
374 [[fully_dist]]
375 === Fully-distributed
376
377 By default, HBase runs in standalone mode.
378 Both standalone mode and pseudo-distributed mode are provided for the purposes of small-scale testing.
379 For a production environment, distributed mode is advised.
380 In distributed mode, multiple instances of HBase daemons run on multiple servers in the cluster.
381
382 Just as in pseudo-distributed mode, a fully distributed configuration requires that you set the `hbase.cluster.distributed` property to `true`.
383 Typically, the `hbase.rootdir` is configured to point to a highly-available HDFS filesystem.
384
385 In addition, the cluster is configured so that multiple cluster nodes enlist as RegionServers, ZooKeeper QuorumPeers, and backup HMaster servers.
386 These configuration basics are all demonstrated in <<quickstart_fully_distributed,quickstart-fully-distributed>>.
387
388 .Distributed RegionServers
389 Typically, your cluster will contain multiple RegionServers all running on different servers, as well as primary and backup Master and ZooKeeper daemons.
390 The _conf/regionservers_ file on the master server contains a list of hosts whose RegionServers are associated with this cluster.
391 Each host is on a separate line.
392 All hosts listed in this file will have their RegionServer processes started and stopped when the master server starts or stops.
393
394 .ZooKeeper and HBase
395 See the <<zookeeper,ZooKeeper>> section for ZooKeeper setup instructions for HBase.
396
397 .Example Distributed HBase Cluster
398 ====
399 This is a bare-bones _conf/hbase-site.xml_ for a distributed HBase cluster.
400 A cluster that is used for real-world work would contain more custom configuration parameters.
401 Most HBase configuration directives have default values, which are used unless the value is overridden in the _hbase-site.xml_.
402 See "<<config.files,Configuration Files>>" for more information.
403
404 [source,xml]
405 ----
406
407 <configuration>
408   <property>
409     <name>hbase.rootdir</name>
410     <value>hdfs://namenode.example.org:8020/hbase</value>
411   </property>
412   <property>
413     <name>hbase.cluster.distributed</name>
414     <value>true</value>
415   </property>
416   <property>
417     <name>hbase.zookeeper.quorum</name>
418     <value>node-a.example.com,node-b.example.com,node-c.example.com</value>
419   </property>
420 </configuration>
421 ----
422
423 This is an example _conf/regionservers_ file, which contains a list of nodes that should run a RegionServer in the cluster.
424 These nodes need HBase installed and they need to use the same contents of the _conf/_ directory as the Master server
425
426 [source]
427 ----
428
429 node-a.example.com
430 node-b.example.com
431 node-c.example.com
432 ----
433
434 This is an example _conf/backup-masters_ file, which contains a list of each node that should run a backup Master instance.
435 The backup Master instances will sit idle unless the main Master becomes unavailable.
436
437 [source]
438 ----
439
440 node-b.example.com
441 node-c.example.com
442 ----
443 ====
444
445 .Distributed HBase Quickstart
446 See <<quickstart_fully_distributed,quickstart-fully-distributed>> for a walk-through of a simple three-node cluster configuration with multiple ZooKeeper, backup HMaster, and RegionServer instances.
447
448 .Procedure: HDFS Client Configuration
449 . Of note, if you have made HDFS client configuration changes on your Hadoop cluster, such as configuration directives for HDFS clients, as opposed to server-side configurations, you must use one of the following methods to enable HBase to see and use these configuration changes:
450 +
451 a. Add a pointer to your `HADOOP_CONF_DIR` to the `HBASE_CLASSPATH` environment variable in _hbase-env.sh_.
452 b. Add a copy of _hdfs-site.xml_ (or _hadoop-site.xml_) or, better, symlinks, under _${HBASE_HOME}/conf_, or
453 c. if only a small set of HDFS client configurations, add them to _hbase-site.xml_.
454
455
456 An example of such an HDFS client configuration is `dfs.replication`.
457 If for example, you want to run with a replication factor of 5, HBase will create files with the default of 3 unless you do the above to make the configuration available to HBase.
458
459 [[confirm]]
460 == Running and Confirming Your Installation
461
462 Make sure HDFS is running first.
463 Start and stop the Hadoop HDFS daemons by running _bin/start-hdfs.sh_ over in the `HADOOP_HOME` directory.
464 You can ensure it started properly by testing the `put` and `get` of files into the Hadoop filesystem.
465 HBase does not normally use the MapReduce or YARN daemons. These do not need to be started.
466
467 _If_ you are managing your own ZooKeeper, start it and confirm it's running, else HBase will start up ZooKeeper for you as part of its start process.
468
469 Start HBase with the following command:
470
471 ----
472 bin/start-hbase.sh
473 ----
474
475 Run the above from the `HBASE_HOME` directory.
476
477 You should now have a running HBase instance.
478 HBase logs can be found in the _logs_ subdirectory.
479 Check them out especially if HBase had trouble starting.
480
481 HBase also puts up a UI listing vital attributes.
482 By default it's deployed on the Master host at port 16010 (HBase RegionServers listen on port 16020 by default and put up an informational HTTP server at port 16030). If the Master is running on a host named `master.example.org` on the default port, point your browser at pass:[http://master.example.org:16010] to see the web interface.
483
484 Once HBase has started, see the <<shell_exercises,shell exercises>> section for how to create tables, add data, scan your insertions, and finally disable and drop your tables.
485
486 To stop HBase after exiting the HBase shell enter
487
488 ----
489 $ ./bin/stop-hbase.sh
490 stopping hbase...............
491 ----
492
493 Shutdown can take a moment to complete.
494 It can take longer if your cluster is comprised of many machines.
495 If you are running a distributed operation, be sure to wait until HBase has shut down completely before stopping the Hadoop daemons.
496
497 [[config.files]]
498 == Default Configuration
499
500 [[hbase.site]]
501 === _hbase-site.xml_ and _hbase-default.xml_
502
503 Just as in Hadoop where you add site-specific HDFS configuration to the _hdfs-site.xml_ file, for HBase, site specific customizations go into the file _conf/hbase-site.xml_.
504 For the list of configurable properties, see <<hbase_default_configurations,hbase default configurations>> below or view the raw _hbase-default.xml_ source file in the HBase source code at _src/main/resources_.
505
506 Not all configuration options make it out to _hbase-default.xml_.
507 Some configurations would only appear in source code; the only way to identify these changes are through code review.
508
509 Currently, changes here will require a cluster restart for HBase to notice the change.
510 // hbase/src/main/asciidoc
511 //
512 include::{docdir}/../../../target/asciidoc/hbase-default.adoc[]
513
514
515 [[hbase.env.sh]]
516 === _hbase-env.sh_
517
518 Set HBase environment variables in this file.
519 Examples include options to pass the JVM on start of an HBase daemon such as heap size and garbage collector configs.
520 You can also set configurations for HBase configuration, log directories, niceness, ssh options, where to locate process pid files, etc.
521 Open the file at _conf/hbase-env.sh_ and peruse its content.
522 Each option is fairly well documented.
523 Add your own environment variables here if you want them read by HBase daemons on startup.
524
525 Changes here will require a cluster restart for HBase to notice the change.
526
527 [[log4j]]
528 === _log4j.properties_
529
530 Edit this file to change rate at which HBase files are rolled and to change the level at which HBase logs messages.
531
532 Changes here will require a cluster restart for HBase to notice the change though log levels can be changed for particular daemons via the HBase UI.
533
534 [[client_dependencies]]
535 === Client configuration and dependencies connecting to an HBase cluster
536
537 If you are running HBase in standalone mode, you don't need to configure anything for your client to work provided that they are all on the same machine.
538
539 Since the HBase Master may move around, clients bootstrap by looking to ZooKeeper for current critical locations.
540 ZooKeeper is where all these values are kept.
541 Thus clients require the location of the ZooKeeper ensemble before they can do anything else.
542 Usually this ensemble location is kept out in the _hbase-site.xml_ and is picked up by the client from the `CLASSPATH`.
543
544 If you are configuring an IDE to run an HBase client, you should include the _conf/_ directory on your classpath so _hbase-site.xml_ settings can be found (or add _src/test/resources_ to pick up the hbase-site.xml used by tests).
545
546 Minimally, an HBase client needs hbase-client module in its dependencies when connecting to a cluster:
547 [source,xml]
548 ----
549
550 <dependency>
551   <groupId>org.apache.hbase</groupId>
552   <artifactId>hbase-client</artifactId>
553   <version>1.2.4</version>
554 </dependency>
555 ----
556
557 A basic example _hbase-site.xml_ for client only may look as follows:
558 [source,xml]
559 ----
560 <?xml version="1.0"?>
561 <?xml-stylesheet type="text/xsl" href="configuration.xsl"?>
562 <configuration>
563   <property>
564     <name>hbase.zookeeper.quorum</name>
565     <value>example1,example2,example3</value>
566     <description>The directory shared by region servers.
567     </description>
568   </property>
569 </configuration>
570 ----
571
572 [[java.client.config]]
573 ==== Java client configuration
574
575 The configuration used by a Java client is kept in an link:https://hbase.apache.org/apidocs/org/apache/hadoop/hbase/HBaseConfiguration[HBaseConfiguration] instance.
576
577 The factory method on HBaseConfiguration, `HBaseConfiguration.create();`, on invocation, will read in the content of the first _hbase-site.xml_ found on the client's `CLASSPATH`, if one is present (Invocation will also factor in any _hbase-default.xml_ found; an _hbase-default.xml_ ships inside the _hbase.X.X.X.jar_). It is also possible to specify configuration directly without having to read from a _hbase-site.xml_.
578 For example, to set the ZooKeeper ensemble for the cluster programmatically do as follows:
579
580 [source,java]
581 ----
582 Configuration config = HBaseConfiguration.create();
583 config.set("hbase.zookeeper.quorum", "localhost");  // Here we are running zookeeper locally
584 ----
585
586 If multiple ZooKeeper instances make up your ZooKeeper ensemble, they may be specified in a comma-separated list (just as in the _hbase-site.xml_ file). This populated `Configuration` instance can then be passed to an link:https://hbase.apache.org/apidocs/org/apache/hadoop/hbase/client/Table.html[Table], and so on.
587
588 [[example_config]]
589 == Example Configurations
590
591 === Basic Distributed HBase Install
592
593 Here is a basic configuration example for a distributed ten node cluster:
594 * The nodes are named `example0`, `example1`, etc., through node `example9` in this example.
595 * The HBase Master and the HDFS NameNode are running on the node `example0`.
596 * RegionServers run on nodes `example1`-`example9`.
597 * A 3-node ZooKeeper ensemble runs on `example1`, `example2`, and `example3` on the default ports.
598 * ZooKeeper data is persisted to the directory _/export/zookeeper_.
599
600 Below we show what the main configuration files -- _hbase-site.xml_, _regionservers_, and _hbase-env.sh_ -- found in the HBase _conf_ directory might look like.
601
602 [[hbase_site]]
603 ==== _hbase-site.xml_
604
605 [source,xml]
606 ----
607 <?xml version="1.0"?>
608 <?xml-stylesheet type="text/xsl" href="configuration.xsl"?>
609 <configuration>
610   <property>
611     <name>hbase.zookeeper.quorum</name>
612     <value>example1,example2,example3</value>
613     <description>The directory shared by RegionServers.
614     </description>
615   </property>
616   <property>
617     <name>hbase.zookeeper.property.dataDir</name>
618     <value>/export/zookeeper</value>
619     <description>Property from ZooKeeper config zoo.cfg.
620     The directory where the snapshot is stored.
621     </description>
622   </property>
623   <property>
624     <name>hbase.rootdir</name>
625     <value>hdfs://example0:8020/hbase</value>
626     <description>The directory shared by RegionServers.
627     </description>
628   </property>
629   <property>
630     <name>hbase.cluster.distributed</name>
631     <value>true</value>
632     <description>The mode the cluster will be in. Possible values are
633       false: standalone and pseudo-distributed setups with managed ZooKeeper
634       true: fully-distributed with unmanaged ZooKeeper Quorum (see hbase-env.sh)
635     </description>
636   </property>
637 </configuration>
638 ----
639
640 [[regionservers]]
641 ==== _regionservers_
642
643 In this file you list the nodes that will run RegionServers.
644 In our case, these nodes are `example1`-`example9`.
645
646 [source]
647 ----
648 example1
649 example2
650 example3
651 example4
652 example5
653 example6
654 example7
655 example8
656 example9
657 ----
658
659 [[hbase_env]]
660 ==== _hbase-env.sh_
661
662 The following lines in the _hbase-env.sh_ file show how to set the `JAVA_HOME` environment variable (required for HBase) and set the heap to 4 GB (rather than the default value of 1 GB). If you copy and paste this example, be sure to adjust the `JAVA_HOME` to suit your environment.
663
664 ----
665 # The java implementation to use.
666 export JAVA_HOME=/usr/java/jdk1.8.0/
667
668 # The maximum amount of heap to use. Default is left to JVM default.
669 export HBASE_HEAPSIZE=4G
670 ----
671
672 Use +rsync+ to copy the content of the _conf_ directory to all nodes of the cluster.
673
674 [[important_configurations]]
675 == The Important Configurations
676
677 Below we list some _important_ configurations.
678 We've divided this section into required configuration and worth-a-look recommended configs.
679
680 [[required_configuration]]
681 === Required Configurations
682
683 Review the <<os,os>> and <<hadoop,hadoop>> sections.
684
685 [[big.cluster.config]]
686 ==== Big Cluster Configurations
687
688 If you have a cluster with a lot of regions, it is possible that a Regionserver checks in briefly after the Master starts while all the remaining RegionServers lag behind. This first server to check in will be assigned all regions which is not optimal.
689 To prevent the above scenario from happening, up the `hbase.master.wait.on.regionservers.mintostart` property from its default value of 1.
690 See link:https://issues.apache.org/jira/browse/HBASE-6389[HBASE-6389 Modify the
691             conditions to ensure that Master waits for sufficient number of Region Servers before
692             starting region assignments] for more detail.
693
694 [[recommended_configurations]]
695 === Recommended Configurations
696
697 [[recommended_configurations.zk]]
698 ==== ZooKeeper Configuration
699
700 [[sect.zookeeper.session.timeout]]
701 ===== `zookeeper.session.timeout`
702
703 The default timeout is three minutes (specified in milliseconds). This means that if a server crashes, it will be three minutes before the Master notices the crash and starts recovery.
704 You might need to tune the timeout down to a minute or even less so the Master notices failures sooner.
705 Before changing this value, be sure you have your JVM garbage collection configuration under control, otherwise, a long garbage collection that lasts beyond the ZooKeeper session timeout will take out your RegionServer. (You might be fine with this -- you probably want recovery to start on the server if a RegionServer has been in GC for a long period of time).
706
707 To change this configuration, edit _hbase-site.xml_, copy the changed file across the cluster and restart.
708
709 We set this value high to save our having to field questions up on the mailing lists asking why a RegionServer went down during a massive import.
710 The usual cause is that their JVM is untuned and they are running into long GC pauses.
711 Our thinking is that while users are getting familiar with HBase, we'd save them having to know all of its intricacies.
712 Later when they've built some confidence, then they can play with configuration such as this.
713
714 [[zookeeper.instances]]
715 ===== Number of ZooKeeper Instances
716
717 See <<zookeeper,zookeeper>>.
718
719 [[recommended.configurations.hdfs]]
720 ==== HDFS Configurations
721
722 [[dfs.datanode.failed.volumes.tolerated]]
723 ===== `dfs.datanode.failed.volumes.tolerated`
724
725 This is the "...number of volumes that are allowed to fail before a DataNode stops offering service.
726 By default any volume failure will cause a datanode to shutdown" from the _hdfs-default.xml_ description.
727 You might want to set this to about half the amount of your available disks.
728
729 [[hbase.regionserver.handler.count]]
730 ===== `hbase.regionserver.handler.count`
731
732 This setting defines the number of threads that are kept open to answer incoming requests to user tables.
733 The rule of thumb is to keep this number low when the payload per request approaches the MB (big puts, scans using a large cache) and high when the payload is small (gets, small puts, ICVs, deletes). The total size of the queries in progress is limited by the setting `hbase.ipc.server.max.callqueue.size`.
734
735 It is safe to set that number to the maximum number of incoming clients if their payload is small, the typical example being a cluster that serves a website since puts aren't typically buffered and most of the operations are gets.
736
737 The reason why it is dangerous to keep this setting high is that the aggregate size of all the puts that are currently happening in a region server may impose too much pressure on its memory, or even trigger an OutOfMemoryError.
738 A RegionServer running on low memory will trigger its JVM's garbage collector to run more frequently up to a point where GC pauses become noticeable (the reason being that all the memory used to keep all the requests' payloads cannot be trashed, no matter how hard the garbage collector tries). After some time, the overall cluster throughput is affected since every request that hits that RegionServer will take longer, which exacerbates the problem even more.
739
740 You can get a sense of whether you have too little or too many handlers by <<rpc.logging,rpc.logging>> on an individual RegionServer then tailing its logs (Queued requests consume memory).
741
742 [[big_memory]]
743 ==== Configuration for large memory machines
744
745 HBase ships with a reasonable, conservative configuration that will work on nearly all machine types that people might want to test with.
746 If you have larger machines -- HBase has 8G and larger heap -- you might find the following configuration options helpful.
747 TODO.
748
749 [[config.compression]]
750 ==== Compression
751
752 You should consider enabling ColumnFamily compression.
753 There are several options that are near-frictionless and in most all cases boost performance by reducing the size of StoreFiles and thus reducing I/O.
754
755 See <<compression,compression>> for more information.
756
757 [[config.wals]]
758 ==== Configuring the size and number of WAL files
759
760 HBase uses <<wal,wal>> to recover the memstore data that has not been flushed to disk in case of an RS failure.
761 These WAL files should be configured to be slightly smaller than HDFS block (by default a HDFS block is 64Mb and a WAL file is ~60Mb).
762
763 HBase also has a limit on the number of WAL files, designed to ensure there's never too much data that needs to be replayed during recovery.
764 This limit needs to be set according to memstore configuration, so that all the necessary data would fit.
765 It is recommended to allocate enough WAL files to store at least that much data (when all memstores are close to full). For example, with 16Gb RS heap, default memstore settings (0.4), and default WAL file size (~60Mb), 16Gb*0.4/60, the starting point for WAL file count is ~109.
766 However, as all memstores are not expected to be full all the time, less WAL files can be allocated.
767
768 [[disable.splitting]]
769 ==== Managed Splitting
770
771 HBase generally handles splitting of your regions based upon the settings in your _hbase-default.xml_ and _hbase-site.xml_          configuration files.
772 Important settings include `hbase.regionserver.region.split.policy`, `hbase.hregion.max.filesize`, `hbase.regionserver.regionSplitLimit`.
773 A simplistic view of splitting is that when a region grows to `hbase.hregion.max.filesize`, it is split.
774 For most usage patterns, you should use automatic splitting.
775 See <<manual_region_splitting_decisions,manual region splitting decisions>> for more information about manual region splitting.
776
777 Instead of allowing HBase to split your regions automatically, you can choose to manage the splitting yourself.
778 This feature was added in HBase 0.90.0.
779 Manually managing splits works if you know your keyspace well, otherwise let HBase figure where to split for you.
780 Manual splitting can mitigate region creation and movement under load.
781 It also makes it so region boundaries are known and invariant (if you disable region splitting). If you use manual splits, it is easier doing staggered, time-based major compactions to spread out your network IO load.
782
783 .Disable Automatic Splitting
784 To disable automatic splitting, you can set region split policy in either cluster configuration or table configuration to be `org.apache.hadoop.hbase.regionserver.DisabledRegionSplitPolicy`
785
786 .Automatic Splitting Is Recommended
787 [NOTE]
788 ====
789 If you disable automatic splits to diagnose a problem or during a period of fast data growth, it is recommended to re-enable them when your situation becomes more stable.
790 The potential benefits of managing region splits yourself are not undisputed.
791 ====
792
793 .Determine the Optimal Number of Pre-Split Regions
794 The optimal number of pre-split regions depends on your application and environment.
795 A good rule of thumb is to start with 10 pre-split regions per server and watch as data grows over time.
796 It is better to err on the side of too few regions and perform rolling splits later.
797 The optimal number of regions depends upon the largest StoreFile in your region.
798 The size of the largest StoreFile will increase with time if the amount of data grows.
799 The goal is for the largest region to be just large enough that the compaction selection algorithm only compacts it during a timed major compaction.
800 Otherwise, the cluster can be prone to compaction storms with a large number of regions under compaction at the same time.
801 It is important to understand that the data growth causes compaction storms and not the manual split decision.
802
803 If the regions are split into too many large regions, you can increase the major compaction interval by configuring `HConstants.MAJOR_COMPACTION_PERIOD`.
804 HBase 0.90 introduced `org.apache.hadoop.hbase.util.RegionSplitter`, which provides a network-IO-safe rolling split of all regions.
805
806 [[managed.compactions]]
807 ==== Managed Compactions
808
809 By default, major compactions are scheduled to run once in a 7-day period.
810 Prior to HBase 0.96.x, major compactions were scheduled to happen once per day by default.
811
812 If you need to control exactly when and how often major compaction runs, you can disable managed major compactions.
813 See the entry for `hbase.hregion.majorcompaction` in the <<compaction.parameters,compaction.parameters>> table for details.
814
815 .Do Not Disable Major Compactions
816 [WARNING]
817 ====
818 Major compactions are absolutely necessary for StoreFile clean-up.
819 Do not disable them altogether.
820 You can run major compactions manually via the HBase shell or via the link:https://hbase.apache.org/apidocs/org/apache/hadoop/hbase/client/Admin.html#majorCompact-org.apache.hadoop.hbase.TableName-[Admin API].
821 ====
822
823 For more information about compactions and the compaction file selection process, see <<compaction,compaction>>
824
825 [[spec.ex]]
826 ==== Speculative Execution
827
828 Speculative Execution of MapReduce tasks is on by default, and for HBase clusters it is generally advised to turn off Speculative Execution at a system-level unless you need it for a specific case, where it can be configured per-job.
829 Set the properties `mapreduce.map.speculative` and `mapreduce.reduce.speculative` to false.
830
831 [[other_configuration]]
832 === Other Configurations
833
834 [[balancer_config]]
835 ==== Balancer
836
837 The balancer is a periodic operation which is run on the master to redistribute regions on the cluster.
838 It is configured via `hbase.balancer.period` and defaults to 300000 (5 minutes).
839
840 See <<master.processes.loadbalancer,master.processes.loadbalancer>> for more information on the LoadBalancer.
841
842 [[disabling.blockcache]]
843 ==== Disabling Blockcache
844
845 Do not turn off block cache (You'd do it by setting `hfile.block.cache.size` to zero). Currently we do not do well if you do this because the RegionServer will spend all its time loading HFile indices over and over again.
846 If your working set is such that block cache does you no good, at least size the block cache such that HFile indices will stay up in the cache (you can get a rough idea on the size you need by surveying RegionServer UIs; you'll see index block size accounted near the top of the webpage).
847
848 [[nagles]]
849 ==== link:http://en.wikipedia.org/wiki/Nagle's_algorithm[Nagle's] or the small package problem
850
851 If a big 40ms or so occasional delay is seen in operations against HBase, try the Nagles' setting.
852 For example, see the user mailing list thread, link:http://search-hadoop.com/m/pduLg2fydtE/Inconsistent+scan+performance+with+caching+set+&subj=Re+Inconsistent+scan+performance+with+caching+set+to+1[Inconsistent scan performance with caching set to 1] and the issue cited therein where setting `notcpdelay` improved scan speeds.
853 You might also see the graphs on the tail of link:https://issues.apache.org/jira/browse/HBASE-7008[HBASE-7008 Set scanner caching to a better default] where our Lars Hofhansl tries various data sizes w/ Nagle's on and off measuring the effect.
854
855 [[mttr]]
856 ==== Better Mean Time to Recover (MTTR)
857
858 This section is about configurations that will make servers come back faster after a fail.
859 See the Deveraj Das and Nicolas Liochon blog post link:http://hortonworks.com/blog/introduction-to-hbase-mean-time-to-recover-mttr/[Introduction to HBase Mean Time to Recover (MTTR)] for a brief introduction.
860
861 The issue link:https://issues.apache.org/jira/browse/HBASE-8389[HBASE-8354 forces Namenode into loop with lease recovery requests] is messy but has a bunch of good discussion toward the end on low timeouts and how to cause faster recovery including citation of fixes added to HDFS. Read the Varun Sharma comments.
862 The below suggested configurations are Varun's suggestions distilled and tested.
863 Make sure you are running on a late-version HDFS so you have the fixes he refers to and himself adds to HDFS that help HBase MTTR (e.g.
864 HDFS-3703, HDFS-3712, and HDFS-4791 -- Hadoop 2 for sure has them and late Hadoop 1 has some). Set the following in the RegionServer.
865
866 [source,xml]
867 ----
868 <property>
869   <name>hbase.lease.recovery.dfs.timeout</name>
870   <value>23000</value>
871   <description>How much time we allow elapse between calls to recover lease.
872   Should be larger than the dfs timeout.</description>
873 </property>
874 <property>
875   <name>dfs.client.socket-timeout</name>
876   <value>10000</value>
877   <description>Down the DFS timeout from 60 to 10 seconds.</description>
878 </property>
879 ----
880
881 And on the NameNode/DataNode side, set the following to enable 'staleness' introduced in HDFS-3703, HDFS-3912.
882
883 [source,xml]
884 ----
885 <property>
886   <name>dfs.client.socket-timeout</name>
887   <value>10000</value>
888   <description>Down the DFS timeout from 60 to 10 seconds.</description>
889 </property>
890 <property>
891   <name>dfs.datanode.socket.write.timeout</name>
892   <value>10000</value>
893   <description>Down the DFS timeout from 8 * 60 to 10 seconds.</description>
894 </property>
895 <property>
896   <name>ipc.client.connect.timeout</name>
897   <value>3000</value>
898   <description>Down from 60 seconds to 3.</description>
899 </property>
900 <property>
901   <name>ipc.client.connect.max.retries.on.timeouts</name>
902   <value>2</value>
903   <description>Down from 45 seconds to 3 (2 == 3 retries).</description>
904 </property>
905 <property>
906   <name>dfs.namenode.avoid.read.stale.datanode</name>
907   <value>true</value>
908   <description>Enable stale state in hdfs</description>
909 </property>
910 <property>
911   <name>dfs.namenode.stale.datanode.interval</name>
912   <value>20000</value>
913   <description>Down from default 30 seconds</description>
914 </property>
915 <property>
916   <name>dfs.namenode.avoid.write.stale.datanode</name>
917   <value>true</value>
918   <description>Enable stale state in hdfs</description>
919 </property>
920 ----
921
922 [[jmx_config]]
923 ==== JMX
924
925 JMX (Java Management Extensions) provides built-in instrumentation that enables you to monitor and manage the Java VM.
926 To enable monitoring and management from remote systems, you need to set system property `com.sun.management.jmxremote.port` (the port number through which you want to enable JMX RMI connections) when you start the Java VM.
927 See the link:http://docs.oracle.com/javase/8/docs/technotes/guides/management/agent.html[official documentation] for more information.
928 Historically, besides above port mentioned, JMX opens two additional random TCP listening ports, which could lead to port conflict problem. (See link:https://issues.apache.org/jira/browse/HBASE-10289[HBASE-10289] for details)
929
930 As an alternative, You can use the coprocessor-based JMX implementation provided by HBase.
931 To enable it in 0.99 or above, add below property in _hbase-site.xml_:
932
933 [source,xml]
934 ----
935 <property>
936   <name>hbase.coprocessor.regionserver.classes</name>
937   <value>org.apache.hadoop.hbase.JMXListener</value>
938 </property>
939 ----
940
941 NOTE: DO NOT set `com.sun.management.jmxremote.port` for Java VM at the same time.
942
943 Currently it supports Master and RegionServer Java VM.
944 By default, the JMX listens on TCP port 10102, you can further configure the port using below properties:
945
946 [source,xml]
947 ----
948 <property>
949   <name>regionserver.rmi.registry.port</name>
950   <value>61130</value>
951 </property>
952 <property>
953   <name>regionserver.rmi.connector.port</name>
954   <value>61140</value>
955 </property>
956 ----
957
958 The registry port can be shared with connector port in most cases, so you only need to configure regionserver.rmi.registry.port.
959 However if you want to use SSL communication, the 2 ports must be configured to different values.
960
961 By default the password authentication and SSL communication is disabled.
962 To enable password authentication, you need to update _hbase-env.sh_          like below:
963 [source,bash]
964 ----
965 export HBASE_JMX_BASE="-Dcom.sun.management.jmxremote.authenticate=true                  \
966                        -Dcom.sun.management.jmxremote.password.file=your_password_file   \
967                        -Dcom.sun.management.jmxremote.access.file=your_access_file"
968
969 export HBASE_MASTER_OPTS="$HBASE_MASTER_OPTS $HBASE_JMX_BASE "
970 export HBASE_REGIONSERVER_OPTS="$HBASE_REGIONSERVER_OPTS $HBASE_JMX_BASE "
971 ----
972
973 See example password/access file under _$JRE_HOME/lib/management_.
974
975 To enable SSL communication with password authentication, follow below steps:
976
977 [source,bash]
978 ----
979 #1. generate a key pair, stored in myKeyStore
980 keytool -genkey -alias jconsole -keystore myKeyStore
981
982 #2. export it to file jconsole.cert
983 keytool -export -alias jconsole -keystore myKeyStore -file jconsole.cert
984
985 #3. copy jconsole.cert to jconsole client machine, import it to jconsoleKeyStore
986 keytool -import -alias jconsole -keystore jconsoleKeyStore -file jconsole.cert
987 ----
988
989 And then update _hbase-env.sh_ like below:
990
991 [source,bash]
992 ----
993 export HBASE_JMX_BASE="-Dcom.sun.management.jmxremote.ssl=true                         \
994                        -Djavax.net.ssl.keyStore=/home/tianq/myKeyStore                 \
995                        -Djavax.net.ssl.keyStorePassword=your_password_in_step_1       \
996                        -Dcom.sun.management.jmxremote.authenticate=true                \
997                        -Dcom.sun.management.jmxremote.password.file=your_password file \
998                        -Dcom.sun.management.jmxremote.access.file=your_access_file"
999
1000 export HBASE_MASTER_OPTS="$HBASE_MASTER_OPTS $HBASE_JMX_BASE "
1001 export HBASE_REGIONSERVER_OPTS="$HBASE_REGIONSERVER_OPTS $HBASE_JMX_BASE "
1002 ----
1003
1004 Finally start `jconsole` on the client using the key store:
1005
1006 [source,bash]
1007 ----
1008 jconsole -J-Djavax.net.ssl.trustStore=/home/tianq/jconsoleKeyStore
1009 ----
1010
1011 NOTE: To enable the HBase JMX implementation on Master, you also need to add below property in _hbase-site.xml_:
1012
1013 [source,xml]
1014 ----
1015 <property>
1016   <name>hbase.coprocessor.master.classes</name>
1017   <value>org.apache.hadoop.hbase.JMXListener</value>
1018 </property>
1019 ----
1020
1021 The corresponding properties for port configuration are `master.rmi.registry.port` (by default 10101) and `master.rmi.connector.port` (by default the same as registry.port)
1022
1023 [[dyn_config]]
1024 == Dynamic Configuration
1025
1026 Since HBase 1.0.0, it is possible to change a subset of the configuration without requiring a server restart.
1027 In the HBase shell, there are new operators, `update_config` and `update_all_config` that will prompt a server or all servers to reload configuration.
1028
1029 Only a subset of all configurations can currently be changed in the running server.
1030 Here are those configurations:
1031
1032 .Configurations support dynamically change
1033 [cols="1",options="header"]
1034 |===
1035 | Key
1036 | hbase.ipc.server.fallback-to-simple-auth-allowed
1037 | hbase.cleaner.scan.dir.concurrent.size
1038 | hbase.regionserver.thread.compaction.large
1039 | hbase.regionserver.thread.compaction.small
1040 | hbase.regionserver.thread.split
1041 | hbase.regionserver.throughput.controller
1042 | hbase.regionserver.thread.hfilecleaner.throttle
1043 | hbase.regionserver.hfilecleaner.large.queue.size
1044 | hbase.regionserver.hfilecleaner.small.queue.size
1045 | hbase.regionserver.hfilecleaner.large.thread.count
1046 | hbase.regionserver.hfilecleaner.small.thread.count
1047 | hbase.regionserver.flush.throughput.controller
1048 | hbase.hstore.compaction.max.size
1049 | hbase.hstore.compaction.max.size.offpeak
1050 | hbase.hstore.compaction.min.size
1051 | hbase.hstore.compaction.min
1052 | hbase.hstore.compaction.max
1053 | hbase.hstore.compaction.ratio
1054 | hbase.hstore.compaction.ratio.offpeak
1055 | hbase.regionserver.thread.compaction.throttle
1056 | hbase.hregion.majorcompaction
1057 | hbase.hregion.majorcompaction.jitter
1058 | hbase.hstore.min.locality.to.skip.major.compact
1059 | hbase.hstore.compaction.date.tiered.max.storefile.age.millis
1060 | hbase.hstore.compaction.date.tiered.incoming.window.min
1061 | hbase.hstore.compaction.date.tiered.window.policy.class
1062 | hbase.hstore.compaction.date.tiered.single.output.for.minor.compaction
1063 | hbase.hstore.compaction.date.tiered.window.factory.class
1064 | hbase.offpeak.start.hour
1065 | hbase.offpeak.end.hour
1066 | hbase.oldwals.cleaner.thread.size
1067 | hbase.procedure.worker.keep.alive.time.msec
1068 | hbase.procedure.worker.add.stuck.percentage
1069 | hbase.procedure.worker.monitor.interval.msec
1070 | hbase.procedure.worker.stuck.threshold.msec
1071 | hbase.regions.slop
1072 | hbase.regions.overallSlop
1073 | hbase.balancer.tablesOnMaster
1074 | hbase.balancer.tablesOnMaster.systemTablesOnly
1075 | hbase.util.ip.to.rack.determiner
1076 | hbase.ipc.server.max.callqueue.length
1077 | hbase.ipc.server.priority.max.callqueue.length
1078 | hbase.ipc.server.callqueue.type
1079 | hbase.ipc.server.callqueue.codel.target.delay
1080 | hbase.ipc.server.callqueue.codel.interval
1081 | hbase.ipc.server.callqueue.codel.lifo.threshold
1082 | hbase.master.balancer.stochastic.maxSteps
1083 | hbase.master.balancer.stochastic.stepsPerRegion
1084 | hbase.master.balancer.stochastic.maxRunningTime
1085 | hbase.master.balancer.stochastic.runMaxSteps
1086 | hbase.master.balancer.stochastic.numRegionLoadsToRemember
1087 | hbase.master.loadbalance.bytable
1088 | hbase.master.balancer.stochastic.minCostNeedBalance
1089 | hbase.master.balancer.stochastic.localityCost
1090 | hbase.master.balancer.stochastic.rackLocalityCost
1091 | hbase.master.balancer.stochastic.readRequestCost
1092 | hbase.master.balancer.stochastic.writeRequestCost
1093 | hbase.master.balancer.stochastic.memstoreSizeCost
1094 | hbase.master.balancer.stochastic.storefileSizeCost
1095 | hbase.master.balancer.stochastic.regionReplicaHostCostKey
1096 | hbase.master.balancer.stochastic.regionReplicaRackCostKey
1097 | hbase.master.balancer.stochastic.regionCountCost
1098 | hbase.master.balancer.stochastic.primaryRegionCountCost
1099 | hbase.master.balancer.stochastic.moveCost
1100 | hbase.master.balancer.stochastic.maxMovePercent
1101 | hbase.master.balancer.stochastic.tableSkewCost
1102 |===
1103
1104 ifdef::backend-docbook[]
1105 [index]
1106 == Index
1107 // Generated automatically by the DocBook toolchain.
1108 endif::backend-docbook[]