Используемое пространство HBASE начало быстро подниматься
Обновление 4 215:
Посмотрев на использование пространства внутри hdfs, я вижу, что.oldlogs использует много места:
1485820612766 /hbase/.oldlogs
Итак, новые вопросы:
- Что это?
- Как мне это почистить?
- Как мне не дать ему снова расти
- Что заставило это начать расти в первую очередь?
- Также.archive тоже большой, что это, мои снимки?
Кроме того, как домашнее задание 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
2 ответа
Я думаю, что моя репликация пошла плохо. Мне кажется, что.oldlogs - это место, куда записываются логи записи (WALS) в соответствии с этой статьей о сафари. Они должны быть очищены, но не по какой-то причине.
Я использовал следующее, чтобы очистить его:
HADOOP_USER_NAME=hdfs hadoop fs -rm -skipTrash /hbase/.oldlogs/*
Так как я заметил это, работая над созданием замещающего кластера в качестве цели репликации, я остановил репликацию на данный момент, и похоже, что каталог больше не становится неограниченным. Это то, что я буду отслеживать в будущем. В частности, потому что кажется, что это может быть ошибкой в соответствии с проблемой hbase 3489.
HBase безопасен при сбое, а.logs - это расположение WAL (хлогов), которые необходимы для восстановления после сбоя. Как только память регионсерверов сбрасывается в hfiles, WAL больше не нужны для восстановления после сбоя, и они перемещаются в.oldlogs. Старые журналы обычно используются для репликации кластера в кластер..oldlogs имеет настраиваемый срок хранения, например, 3 дня. В этом случае, если что-то нарушило вашу репликацию, у вас есть 3 дня, чтобы исправить репликацию без необходимости повторного заполнения. Надеюсь, что это поможет выяснить, что произошло 24 ноября, вызвав рост размера.oldlogs и когда ожидать автоматического удаления hlogs в.oldlogs