Назад | Перейти на главную страницу

Используемое пространство HBASE начало быстро расти

Обновление 4215:
Посмотрев на использование пространства внутри из hdfs, я вижу, что .oldlogs занимает много места:

1485820612766  /hbase/.oldlogs

Итак, новые вопросы:

Также как домашнее задание scollector не будет контролировать использование дискового пространства в различных каталогах hdfs ....

Также похоже, что примерно в то же время в журналы неоднократно начиналась следующая ошибка, не знаю, что именно они означают:

2014-11-25 01:44:47,673 FATAL org.apache.hadoop.hbase.regionserver.wal.HLog: Could not sync. Requesting close of hlog
java.io.IOException: Reflection
    at org.apache.hadoop.hbase.regionserver.wal.SequenceFileLogWriter.sync(SequenceFileLogWriter.java:310)
    at org.apache.hadoop.hbase.regionserver.wal.HLog.syncer(HLog.java:1405)
    at org.apache.hadoop.hbase.regionserver.wal.HLog.syncer(HLog.java:1349)
    at org.apache.hadoop.hbase.regionserver.wal.HLog.sync(HLog.java:1511)
    at org.apache.hadoop.hbase.regionserver.wal.HLog$LogSyncer.run(HLog.java:1301)
    at java.lang.Thread.run(Thread.java:744)
Caused by: java.lang.reflect.InvocationTargetException
    at sun.reflect.GeneratedMethodAccessor30.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:606)
    at org.apache.hadoop.hbase.regionserver.wal.SequenceFileLogWriter.sync(SequenceFileLogWriter.java:308)
    ... 5 more
Caused by: java.io.IOException: Failed to add a datanode.  User may turn off this feature by setting dfs.client.block.write.replace-datanode-on-failure.policy in configuration, where the current policy is DEFAULT.  (Nodes: current=[10.7.0.231:50010, 10.7.0.233:50010], original=[10.7.0.231:50010, 10.7.0.233:50010])
    at org.apache.hadoop.hdfs.DFSOutputStream$DataStreamer.findNewDatanode(DFSOutputStream.java:857)
    at org.apache.hadoop.hdfs.DFSOutputStream$DataStreamer.addDatanode2ExistingPipeline(DFSOutputStream.java:917)
    at org.apache.hadoop.hdfs.DFSOutputStream$DataStreamer.setupPipelineForAppendOrRecovery(DFSOutputStream.java:1023)
    at org.apache.hadoop.hdfs.DFSOutputStream$DataStreamer.processDatanodeError(DFSOutputStream.java:821)
    at org.apache.hadoop.hdfs.DFSOutputStream$DataStreamer.run(DFSOutputStream.java:463)
2014-11-25 01:44:47,673 ERROR org.apache.hadoop.hbase.regionserver.wal.HLog: Error while syncing, requesting close of hlog 

Мое путешествие:

В моем кластере HBASE, который хранит данные openTSBD, мое дисковое пространство начало довольно быстро увеличиваться (хотя, насколько я могу судить, наша скорость вставки была постоянной):

Диски, которые увеличиваются, - это диски хранения HDFS. Каталоги примерно одинакового размера.

Моя установка - это кластер HBASE (сделанный с помощью cloudera), который имеет 3 машины с коэффициентом репликации hdfs равным 3. Существует также еще один кластер с одной машиной, на которую реплицируется основной кластер. Реплика не показывает такого же изменения в росте:

Я делаю снимки на мастере, но list_snapshots из оболочки hbase не показывает возврата более чем на день, поэтому я думаю, что они отбираются, как и должно быть. У меня не очень хороший опыт работы с hbase, есть предложения, что еще посмотреть?

Продвигается...:

[root@ny-tsdb01 ~]# hadoop fs -dus /hbase/*
dus: DEPRECATED: Please use 'du -s' instead.
3308  /hbase/-ROOT-
377401  /hbase/.META.
220097161480  /hbase/.archive
0  /hbase/.corrupt
1537972074  /hbase/.logs
1485820612766  /hbase/.oldlogs
8948367  /hbase/.snapshot
0  /hbase/.tmp
38  /hbase/hbase.id
3  /hbase/hbase.version
192819186494  /hbase/tsdb
905  /hbase/tsdb-meta
899  /hbase/tsdb-tree
1218051  /hbase/tsdb-uid

Я думаю, что моя репликация испортилась. Мне кажется, что .oldlogs - это то место, где идут журналы предзаписи (WALS) в соответствии с эта статья о сафари. Их надо было убрать, но почему-то не было.

Я использовал следующее, чтобы очистить его:

HADOOP_USER_NAME=hdfs hadoop fs -rm -skipTrash /hbase/.oldlogs/*

Поскольку я заметил это, работая над созданием заменяющего кластера в качестве цели репликации, я остановил репликацию на данный момент, и, похоже, каталог больше не растет неограниченно. Это то, что я буду отслеживать в будущем. В частности, потому что кажется, что это может быть ошибка в соответствии с hbase, выпуск 3489.

HBase защищен от сбоев, а .logs - это расположение WAL (hlogs), необходимых для восстановления после сбоя. Как только память региональных серверов сбрасывается в hfiles, WAL больше не нужны для восстановления после сбоя, и они перемещаются в .oldlogs. Старые журналы обычно используются для репликации кластера в кластер. .oldlogs имеют настраиваемый срок хранения, например 3 дня. В этом случае, если что-то сломало вашу репликацию, у вас есть 3 дня, чтобы исправить репликацию без необходимости повторного заполнения. Надеюсь, это поможет выяснить, что произошло 24 ноября, вызвав рост размера .oldlogs, и когда ожидать автоматического удаления hlogs в .oldlogs.