Обновление 4,215:
После рассмотрения использования пространства в 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 issue 3489 .
HBase защищен от сбоев, а .logs - это расположение WAL (hlogs)которые необходимы для восстановления после сбоя. Как только память региональных серверов сбрасывается в hfiles, WAL больше не нужны для восстановления после сбоя, и они перемещаются в .oldlogs. Старые журналы обычно используются для репликации кластера в кластер. .oldlogs имеют настраиваемый период хранения, например 3 дня. В этом случае, если что-то сломало вашу репликацию, у вас есть 3 дня, чтобы исправить репликацию без необходимости повторного заполнения. Надеюсь, это поможет выяснить, что произошло 24 ноября, вызвав рост размера .oldlogs, и когда ожидать автоматического удаления hlogs в .oldlogs