【问题标题】:Backup repository size is much bigger than indices size备份存储库大小远大于索引大小
【发布时间】:2016-04-15 07:40:15
【问题描述】:

我每小时有一个Elasticsearch备份,经过大约370次备份(大约15天),我的备份库超过15G!!!但是总索引大小只有大约 500M ! Elasticsearch 是增量备份,但是 15G VS 500M,差别太大了!我想知道索引和备份存储库之间的大小差异如此之大是否正常?

是不是我的频繁备份(每小时)造成的?我使用集群 1 中的每小时备份和集群 2 中的每小时恢复来保持两个 ES 集群数据实时相同。

我正在使用 Elasticsearch 备份 API 进行备份

  1. 设置回购: curl -XPUT "http://IP:9200/_snapshot/backup" -d "{\"type\": \"fs\",\"settings\": {\"compress\" : true,\"location\": \"backup\" }}"

  2. 备份: CURTIME=date +"%Y-%m-%d %H:%M:%S" BKTIME=${CURTIME//[- :]/} curl -XPUT "http://IP:9200/snapshot/backup/snapshot$BKTIME?wait_for_completion=true"

我的 Elasticsearch 设置:2 个节点、12 个分片/节点、2 个索引、fs 类型的备份以将快照存储到 NAS

在 Elasticsearch 数据目录中,索引大小:

node1 索引大小: [root@esnode1 索引]$ du -sh

307M .

node2 索引大小 [root@esnode2 索引]$ du -sh

238M .

[root@esnode1 索引]$ du -lh

8.0K ./index1/10/translog 8.0K ./index1/10/_state 2.9M ./index1/10/index 2.9M ./index1/10 12K ./index1/5/translog 8.0K ./index1/5/_state 1.5M ./index1/5/index 1.5M ./index1/5 8.0K ./index1/4/translog 8.0K ./index1/4/_state 2.9M ./index1/4/index 2.9M ./index1/4 8.0K ./index1/_state 8.0K ./index1/7/translog 8.0K ./index1/7/_state 2.9M ./index1/7/index 2.9M ./index1/7 8.0K ./index1/1/translog 8.0K ./index1/1/_state 2.9M ./index1/1/index 2.9M ./index1/1 8.0K ./index1/2/translog 8.0K ./index1/2/_state 2.9M ./index1/2/index 2.9M ./index1/2 8.0K ./index1/6/translog 8.0K ./index1/6/_state 3.0M ./index1/6/index 3.0M ./index1/6 8.0K ./index1/0/translog 8.0K ./index1/0/_state 1.5M ./index1/0/index 1.5M ./index1/0 8.0K ./index1/8/translog 8.0K ./index1/8/_state 1.5M ./index1/8/index 1.5M ./index1/8 8.0K ./index1/11/translog 8.0K ./index1/11/_state 2.9M ./index1/11/index 2.9M ./index1/11 12K ./index1/9/translog 8.0K ./index1/9/_state 3.0M ./index1/9/index 3.0M ./index1/9 8.0K ./index1/3/translog 8.0K ./index1/3/_state 3.0M ./index1/3/index 3.0M ./index1/3 31M ./index1 16K ./index2/10/translog 8.0K ./index2/10/_state 16M ./index2/10/index 16M ./index2/10 36K ./index2/5/translog 8.0K ./index2/5/_state 43M ./index2/5/index 43M ./index2/5 20K ./index2/4/translog 8.0K ./index2/4/_state 17M ./index2/4/index 18M ./index2/4 8.0K ./index2/_state 40K ./index2/7/translog 8.0K ./index2/7/_state 32M ./index2/7/index 32M ./index2/7 68K ./index2/1/translog 8.0K ./index2/1/_state 21M ./index2/1/index 21M ./index2/1 64K ./index2/2/translog 8.0K ./index2/2/_state 19M ./index2/2/index 19M ./index2/2 116K ./index2/6/translog 8.0K ./index2/6/_state 22M ./index2/6/index 22M ./index2/6 24K ./index2/0/translog 8.0K ./index2/0/_state 17M ./index2/0/index 17M ./index2/0 128K ./index2/8/translog 8.0K ./index2/8/_state 34M ./index2/8/index 34M ./index2/8 72K ./index2/11/translog 8.0K ./index2/11/_state 20M ./index2/11/index 20M ./index2/11 88K ./index2/9/translog 8.0K ./index2/9/_state 22M ./index2/9/index 22M ./index2/9 76K ./index2/3/translog 8.0K ./index2/3/_state 16M ./index2/3/index 16M ./index2/3 277M ./index2 307M。

在备份存储库中,大小: [root@esnode1 备份]$ du -lh

114M ./backup/indices/index1/0

112M ./backup/indices/index1/5

114M ./backup/indices/index1/11

114M ./backup/indices/index1/10

111M ./backup/indices/index1/8

116M ./backup/indices/index1/4

120M ./backup/indices/index1/9

118M ./backup/indices/index1/3

114M ./backup/indices/index1/2

115M ./backup/indices/index1/7

115M ./backup/indices/index1/1

112M ./backup/indices/index1/6

1.4G ./backup/indices/index1

747M ./backup/indices/index2/0

1.6G ./backup/indices/index2/5

887M ./backup/indices/index2/11

743M ./backup/indices/index2/10

2.1G ./backup/indices/index2/8

801M ./backup/indices/index2/4

1.3G ./backup/indices/index2/9

878M ./backup/indices/index2/3

951M ./backup/indices/index2/2

1.2G ./backup/indices/index2/7

953M ./backup/indices/index2/1

943M ./backup/indices/index2/6

13G ./backup/indices/index2

15G ./备份/索引

15G ./备份

1.1M ./backuplogs

15G。

====== https://www.elastic.co/blog/introducing-snapshot-restore 备份和恢复操作都是增量的,这意味着只有自上次快照后发生更改的文件才会被复制到存储库或恢复到索引中。 增量快照允许根据需要频繁地执行快照操作,而不会产生过多的磁盘空间开销。 用户现在可以在升级或集群中的危险更改之前轻松创建快照,并在以下情况下快速回滚到以前的索引状态事情出错了。快照/恢复机制还可用于在不同地理区域的“热”集群和远程“冷”备份集群之间同步数据,以实现快速灾难恢复。

从以上来看,我的情况确实是个问题,有人可以帮助我吗?提前致谢!

【问题讨论】:

  • 如何触发每小时备份?
  • 在 /var/spool/cron/root 0 1 * * * /opt/es/ESBackup.sh >> /backup/log/backup_$(date +\%Y -\%m-\%d).log
  • 您的 shell 脚本是使用快照/恢复还是只是复制数据文件夹?在后一种情况下,要知道在不先关闭索引的情况下不要复制数据文件夹,否则会有复制不一致数据的风险。
  • 我正在使用 Elasticsearch 备份/恢复 API 设置 repo: curl -XPUT "IP:9200/_snapshot/backup" -d "{\"type\": \"fs\",\"settings\": { \"compress\" : true,\"location\": \"backup\"}}" 备份: CURTIME=date +"%Y-%m-%d %H:%M:%S" BKTIME=${ CURTIME//[- :]/} curl -XPUT "IP:9200/snapshot/backup/…"
  • 您可以使用数据文件夹的du -lh 编辑/更新您的问题吗?

标签: elasticsearch


【解决方案1】:

在 Elasticsearch 官方论坛确认

1) 在我的情况下,索引和备份存储库有很大的不同(500G VS 15G)是正常结果

2) 备份快照中的部分冗余数据是由于Lucene的段合并造成的

来自 Elasticsearch 专家:如果您不断地在集群中建立索引,则段的合并将在后台不断发生,并且随着时间的推移,相同的记录最终会出现在多个段中,从而导致存储库远大于索引大小.

https://discuss.elastic.co/t/backup-repository-size-is-much-bigger-than-indices-size/47469/7

【讨论】:

    【解决方案2】:

    快照和恢复工作在分段级别,这是非常重要的信息,在 Elastic“快照和恢复”文档中没有提到。 我向 Elastic 报告了此事,并询问他们是否可以更新文档。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 2020-02-01
      • 2015-10-16
      • 2011-03-14
      • 1970-01-01
      • 2012-07-28
      • 1970-01-01
      • 2020-09-27
      相关资源
      最近更新 更多