ElasticSearch的备份迁移方案

使用插件repository-hdfs插件进行测试

下载地址:

https://oss.sonatype.org/content/repositories/snapshots/org/elasticsearch/elasticsearch-repository-hdfs/

https://oss.sonatype.org/content/repositories/snapshots/org/elasticsearch/elasticsearch-repository-hdfs/2.3.4.BUILD-SNAPSHOT/elasticsearch-repository-hdfs-2.3.4.BUILD-20160731.045929-24-hadoop2.zip

1、需要分发到各个节点,然后进行安装

bin/plugin install file:///home/dinpay/elasticsearch-repository-hdfs-2.3.4.BUILD-20160731.045929-24-hadoop2.zip

2、将hadoop的etc/hadoop 的hdfs-site.xml和core-site.xml复制到es的每个节点的config目录下(高可用需要的操作)

3、在elasticsearch.yml配置文件后加上

# 禁用jsm,使快照能保存于hdfs

security.manager.enabled: false

repositories.hdfs:

uri: "hdfs://bi"

path: "/es"

load_defaults: "true"

concurrent_streams: 5

conf_location: "core-site.xml,hdfs-site.xml"

compress: "true"

conf.dfs.client.read.shortcircuit: "true"

4、使用kopf插件

#kopf插件 
bin/plugin install lmenezes/elasticsearch-kopf

#head插件

bin/plugin install mobz/elasticsearch-head

通过hadoop的文件操作实现迁移文件操作

时间: 2024-08-06 16:06:24

ElasticSearch的备份迁移方案的相关文章

MongoDB迁移方案-冷备份+增量备份恢复

QQ群:465614686 1.  环境构建步骤 (1)线上环境 都是副本集模式 3个业务访问节点+1个隐藏节点 (隐藏节点做hadoop.spark数据同步使用以及数据报表查询等) (2)主机以及配置说明 10.21.18.21  primary节点    优先级为100 10.21.18.22  secondary节点  优先级为90 10.21.18.23  secondary节点  优先级为80 10.21.18.24  隐藏节点       优先级为0 系统配置:128G内存,64Co

[原]不同场景下MySQL的迁移方案

一 为什么要迁移 MySQL 迁移是 DBA 日常维护中的一个工作.迁移,究其本义,无非是把实际存在的物体挪走,保证该物体的完整性以及延续性.就像柔软的沙滩上,两个天真无邪的小孩,把一堆沙子挪向其他地方,铸就内心神往的城堡. 生产环境中,有以下情况需要做迁移工作,如下: 1.磁盘空间不够.比如一些老项目,选用的机型并不一定适用于数据库.随着时间的推移,硬盘很有可能出现短缺: 2.业务出现瓶颈.比如项目中采用单机承担所有的读写业务,业务压力增大,不堪重负.如果 IO 压力在可接受的范围,会采用读写

HBase集群数据迁移方案

一.静态迁移方案 1.在hbase停止的状态下进行数据的迁移. 2.采用Hadoop distcp方式,将以上目录的内容,迁移到另一个集群. 使用add_table.rb进行恢复. 缺点:不太灵活 二.动态迁移方案 -Replication备份方案 -CopyTable方案 -Export and Import方案 1.Replication备份方案 修改hbase-site.xml配置,增加hbase.replication属性, 增加表属性REPLICATION_SCOPE属性. add_p

不同场景下 MySQL 的迁移方案

不同场景下 MySQL 的迁移方案 Posted in MySQL and tagged MySQL, 数据迁移, 方案 on Sep 15, 2015. Viewd 2684 times. 文/温国兵 一 目录 一 目录 二 为什么要迁移 三 MySQL 迁移方案概览 四 MySQL 迁移实战 4.1 场景一 一主一从结构迁移从库 4.2 场景二 一主一从结构迁移指定库 4.3 场景三 一主一从结构双边迁移指定库 4.4 场景四 一主一从结构完整迁移主从 4.5 场景五 双主结构跨机房迁移 4

mysql迁移之巨大数据量快速迁移方案

mysql迁移之巨大数据量快速迁移方案-增量备份及恢复 --chenjianwen 一.前言: 当mysql库的大小达到几十个G或者上百G,迁移起来是一件非常费事的事情,业务中断,导出导入耗费大量的时间:所以,需要考虑怎么去节省时间的问题. 二.方案: 1.制定维护时间,中断业务,登录 mysql,刷新日志 2.全备数据,备份后得到 binlog 日志文件 mysql-bin.000001 3.迁移走之前的 binlog 日志文件,只留下 mysql-bin.000001 4.恢复业务 5.将全

windows下备份mysql方案

总体思想 定时任务调用备份脚本 1.定时任务, 自行研究 2.脚本 c:\mysql_bak\bin\mysqldump.exe -ugbds -pxxxx gbds --hex-blob>c:\mysql_bak\sql\gbds_%date:~0,4%%date:~5,2%%date:~8,2%_%time:~0,2%%time:~3,2%%time:~6,2%.sql 备注: 对于mysqldump.exe可以使用快捷方式复制到使用目录 windows下备份mysql方案,布布扣,bubu

Redis数据迁移方案

场景 Redis实例A ---> Redis实例B,整库全量迁移 方案一: mac环境 brew install npm npm install redis-dump -g 针对RedisA: redis-dump -h host1 -p 6379 -d 1 --json > mydb.json针对RedisB: cat mydb.json | redis-dump --convert | redis-cli 方案二:参考: http://www.zlovezl.cn/articles/mig

中小型数据库 RMAN CATALOG 备份恢复方案(二)

中小型数据库呈现的是数据库并发少,数据库容量小,版本功能受限以及N多单实例等特点.尽管如此,数据库的损失程度也会存在零丢失的情形.企业不愿意花太多的钱又要保证数据库的可靠稳定,可是苦煞了我这些搞DB的.接上一篇文章,中小型数据库 RMAN CATALOG 备份恢复方案(一),我们继续来给出基于中小型数据库的恢复的脚本与其部署. 1.RMAN还原shell脚本 [python] view plain copy print? --下面的shell脚本用于实现数据库的自动还原,还原成功后,数据库被关闭

中小型数据库 RMAN CATALOG 备份恢复方案(一)

对于数据库的稳定性,高可用,跨平台以及海量数据库的处理,Oracle 数据库通常是大型数据库和大企业的首选.尽管如此,仍然不乏很多中小企业想要品尝一下Oracle腥味,因此在Oracle环境中也有不少中小型数据库.出于成本的考虑,通常有可能就搞个标准版了,跑在Linux上.谁叫Oracle太贵呢?对于中小企业而言,选择合理的才是最好的.对我们这些个搞DB的,贵的一定有贵的道理,我们也可以都进多几斗米.哈哈......典型的打工者的心态哟.言归正传,中小企业的成本限制了我们搞高可用,RAC和DG也