首先创建好hdfs 集群,再修改一下 hdfs-site.xml ,添加
<property>
<name>dfs.permissions</name>
<value>false</value>
</property>
因为我的hdfs是用root用户操作的,elasticsearch 是用 es 用户操作的,先禁止dfs的权限检查
之后重启hdfs集群
开始给es添加hdfs插件,
在es的 bin 目录下,执行 ./elasticsearch-plugin install repository-hdfs 等待安装完成,有些慢
安装之后需要你输入yes,来获取对应操作es的权限
那个里面有对应的权限,
之后修改es 的jvm配置
添加: -Djava.security.policy=file:////home/es/elasticsearch/plugins/repository-hdfs/plugin-security.policy
来设置安全策略,之后重启es
开始进行备份。
curl -XPUT '192.168.93.129:9200/my_index/my_type/1' -d '{"id": 1,"name": "aa"}'
curl -XPUT '192.168.93.129:9200/my_index/my_type/2' -d '{"id": 2,"name": "bb"}'
添加了两条数据
curl -XGET 'http://192.168.93.129:9200/_count?pretty' -d '
{
"query": {
"match_all": {}
}
}'
创建索引仓库:
curl -XPUT 'http://192.168.93.129:9200/_snapshot/my_hdfs_repository' -d '
{
"type": "hdfs",
"settings": {
"uri": "hdfs://192.168.93.129:9000/",
"path": "elasticsearch/respositories/my_hdfs_repository",
"conf.dfs.client.read.shortcircuit": "false",
"max_snapshot_bytes_per_sec" : "50mb",
"max_restore_bytes_per_sec" : "50mb"
}
}'
my_hdfs_repository 是仓库的名字
对索引进行snapshotting备份
(1)对所有open的索引进行snapshotting备份
一个仓库可以包含多分snapshot,每个snapshot是一部分索引的备份数据,创建一份snapshot备份时,我们要指定要备份的索引。比如下面这行命令:PUT _snapshot/my_hdfs_repository/snapshot_1,这行命令就会将所有open的索引都放入一个叫做snapshot_1的备份,并且放入my_hdfs_repository仓库中。这个命令会立即返回,然后备份操作会被后台继续进行。如果我们不希望备份操作以后台方式运行,而是希望在前台发送请求时等待备份操作执行完成,那么可以加一个参数即可,比如下面这样:PUT _snapshot/my_backup/snapshot_1?wait_for_completion=true。
curl -XPUT 'http://192.168.93.129:9200/_snapshot/my_hdfs_repository/snapshot_2'
(2)对指定的索引进行snapshotting备份
默认的备份是会备份所有的索引,但是有的时候,可能我们不希望备份所有的索引,有些可能是不重要的数据,而且量很大,没有必要占用我们的hdfs磁盘资源,那么可以指定备份少数重要的数据即可。此时可以使用下面的命令去备份指定的索引:
PUT _snapshot/my_backup/snapshot_2
{
"indices": "index_1,index_2",
"ignore_unavailable": true,
"include_global_state": false,
"partial": true
}
ignore_unavailable如果设置为true的话,那么那些不存在的index就会被忽略掉,不会进行备份过程中。默认情况下,这个参数是不设置的,那么此时如果某个index丢失了,会导致备份过程失败。设置include_global_state为false,可以阻止cluster的全局state也作为snapshot的一部分被备份。默认情况下,如果某个索引的部分primary shard不可用,那么会导致备份过程失败,那么此时可以将partial设置为true。
而且snapshotting的过程是增量进行的,每次执行snapshotting的时候,es会分析已经存在于仓库中的snapshot对应的index file,然后仅仅备份那些自从上次snapshot之后新创建的或者有过修改的index files。这就允许多个snapshot在仓库中可以用一种紧凑的模式来存储。而且snapshotting过程是不会阻塞所有的es读写操作的,然而,在snapshotting开始之后,写入index中的数据,是不会反应到这次snapshot中的。每次snapshot除了创建一份index的副本之外,还可以保存全局的cluster元数据,里面包含了全局的cluster设置和template。
每次只能执行一次snapshot操作,如果某个shard正在被snapshot备份,那么这个shard此时就不能被移动到其他node上去,这会影响shard rebalance的操作。只有在snapshot结束之后,这个shard才能够被移动到其他的node上去。
查看snapshot备份列表
一旦我们在仓库中备份了一些snapshot之后,就可以查看这些snapshot相关的详细信息了,使用这行命令就可以查看指定的snapshot的详细信息:GET _snapshot/my_hdfs_repository/snapshot_1,结果大致如下所示。当然也可以查看所有的snapshot列表,GET _snapshot/my_hdfs_repository/_all。
curl -XGET 'http://192.168.93.129:9200/_snapshot/my_hdfs_repository/snapshot_2?pretty'
5、删除snapshot备份
如果要删除过于陈旧的snapshot备份快照,那么使用下面这行命令即可:DELETE _snapshot/my_backup/snapshot_2。记住,一定要用api去删除snapshot,不要自己手动跑到hdfs里删除这个数据。因为snapshot是增量的,有可能很多snapshot依赖于底层的某一个公共的旧的snapshot segment。但是delete api是理解数据如何增量存储和互相依赖的,所以可以正确的删除那些不用的数据。如果我们自己手工进行hdfs文件删除,可能导致我们的backup数据破损掉,就无法使用了。
curl -XDELETE 'http://192.168.93.129:9200/_snapshot/my_hdfs_repository/snapshot_1'
6、监控snapshotting的进度
使用wait_for_completion可以在前台等待备份完成,但是实际上也没什么必要,因为可能要备份的数据量特别大,难道还等待1个小时??看着是不太现实的,所以一般还是在后台运行备份过程,然后使用另外一个监控api来查看备份的进度,首先可以获取一个snapshot ID:GET _snapshot/my_backup/snapshot_3。如果这个snapshot还在备份过程中,此时我们就可以看到一些信息,比如什么时候开始备份的,已经运行了多长时间,等等。然而,这个api用了跟snapshot一样的线程池去执行,如果我们在备份非常大的shard,进度的更新可能会非常之慢。一个更好的选择是用_status API,GET _snapshot/my_backup/snapshot_3/_status,这个api立即返回最详细的数据。这里我们可以看到总共有几个shard在备份,已经完成了几个,还剩下几个,包括每个索引的shard的备份进度:
curl -XGET 'http://192.168.93.129:9200/_snapshot/my_hdfs_repository/snapshot_1'
7、取消snapshotting备份过程
如果我们想要取消一个正在执行的snapshotting备份过程,比如我们发现备份时间过于长,希望先取消然后在晚上再运行,或者是因为不小心误操作发起了一次备份操作,这个时候就可以运行下面这条命令:DELETE _snapshot/my_backup/snapshot_3。也就是立即删除这个snapshot,这个命令会去取消snapshot的过程,同时将备份了一半的仓库中的数据给删除掉。
curl -XDELETE 'http://192.168.93.129:9200/_snapshot/my_hdfs_repository/snapshot_1'
hdfs仓库。