ES的冷备

Elasticsearch的冷备

Es集群冷备

elasticsearch冷备官方文档

安装NFS和RPC

  • 将es集群的所有机器作为客户端,备份的机器作为服务端
sudo yum install nfs-utils rpcbind
  • 开启自启服务
sudo chkconfig nfs on 
sudo chkconfig rpcbind on
  • 启动NFS和RPC服务
service nfs start
service rpcbind start 

配置服务端

  • 创建共享目录(共享目录自定义)
mkdir share_file
  • 编辑/etc/exports配置共享路径及权限
sudo vim /etc/exports
/home/xxx/share_file *(insecure,rw)

注:(星号表示所有ping通的IP主机都可访问,secure NFS通过1024以下的安全TCP/IP端口发送,insecure NFS通过1024以上的端口发送。Ro 该主机对该共享目录有只读权限,Rw 该主机对该共享目录有读写权限)

  • 重新挂载
sudo exportfs -r
  • 重启NFS服务,好像不用重启也生效了,可以先看看是否挂载成功0
sudo service nfs restart
  • 显示NFS服务器输出的目录列表(即共享目录列表)showmount -e 【IP】
showmount -e localhost 

客户端配置

  • 创建挂载目录(可自定义,如果不手动创建也行,在挂载时会自动创建)
mkdir mount_file
  • 查看服务端的共享目录
showmount -e 【服务端IP】
  • NFS v3.0 挂载
mount -t nfs -o vers=3 【服务端IP】:【服务端共享目录】 【客户端共享目录】 -o proto=tcp -o nolock 
  • 查看挂载路径
df -h
  • 测试
  1. 服务端(share_file路径下)
vi test_nfs

nfs successful!!!
  1. 客户端(mount_file路径下)
ls
cat test_nfs(显示与服务端内容一致,表示配置成功)

Elasticsearch配置

  • 每个节点的elasticsearch.yml的配置
vi elasticsearch.yml
path.repo: /home/sandy/mount_file
  • 创建仓库
PUT /_snapshot/【厂库名称】
{
   "type":"fs",
   "settings":{
     "compress":true,
     "location":"/home/sandy/mount_file,
     "chunk_size": "5g",  				 # 做快照的时候大文件可以被分解成几块的数
     "max_restore_bytes_per_sec":"20mb",  # 每个节点恢复数据的最高速度限制. 默认是 40mb/s
     "max_snapshot_bytes_per_sec":"20mb", # 每个节点做快照的最高速度限制. 默认是 40mb/s
  }
}
  • 获取仓库信息
GET /_snapshot/【厂库名称】
GET /_snapshot/repo*,*【厂库名称中的字符】*     通配符获取
GET /_snapshot/_all              			获取所有
  • 删除仓库
DELETE /_snapshot/【厂库名称】
  • 创建快照,备份多个索引索引,wait_for_completion参数标识此请求是否需要等待快照创建完成,默认立即返回,不等待快照创建结束(备份无需去索引副本,“indices”: “【备份的索引名称1, 2 ,3】”)
PUT /_snapshot/【厂库名称】/【快照名称】?wait_for_completion=true
{
  "indices": "【备份的索引名称】",
  "ignore_unavailable": true,
  "include_global_state": false
}

  • 监控快照进度
GET _snapshot/【厂库名称】/【快照名称】/_status

{
  "snapshots": [
    {
      "snapshot": "report_standby",
      "repository": "es_219_standby",
      "uuid": "lPi5jLbdSBKB3RJ42LADoA",
      "state": "STARTED", 					注:一个正在运行的快照会显示 IN_PROGRESS 作为状态
      "shards_stats": {
        "initializing": 0,
        "started": 5,						注:这个特定快照有5个分片在传输(另外25个已经完成)
        "finalizing": 0,
        "done": 25,
        "failed": 0,
        "total": 30
      },
      ......
}

注:INITIALIZING–>分片在检查集群状态看看自己是否可以被快照。这个一般是非常快的,STARTED-->数据正在被传输到仓库,FINALIZING–>数据传输完成;分片现在在发送快照元数据,DONE–>快照完成,FAILED–>快照处理的时候碰到了错误,这个分片/索引/快照不可能完成了。检查你的日志获取更多信息。

  • 指定恢复的索引并重命名
POST /_snapshot/【厂库名称】/【快照名称】/_restore
{
    "indices": "【备份的索引名称】",
    "rename_pattern": "【备份的索引名称】",
    "rename_replacement": "【自定义恢复的索引名称】"
}


POST /_snapshot/【厂库名称】/【快照名称】/_restore
{
    "indices": "index_1",					    注:只恢复index_1索引,忽略快照中存在其余索引
    "rename_pattern": "index_(.+)",			    注:查找所提供的模式能匹配上的正在恢复的索引
    "rename_replacement": "restored_index_$1",  注:重命名成替代的模式( restored_index_1)
    "index_settings": {
    	"index.number_of_replicas": 0			注:设置恢复索引的副本数量为0
  	}
    
}

注: 和快照类似, restore 命令也会立刻返回,恢复进程会在后台进行。如果你更希望你的 HTTP 调用阻塞直到恢复完成,添加 wait_for_completion 标记

POST _snapshot/【厂库名称】/【快照名称】/_restore?wait_for_completion=true
  • 监控索引恢复信息
GET 【自定义恢复的索引名称】/_recovery 	 注:单独调用恢复指定索引

GET /_recovery/						 注:集群里所有索引,可能包括跟你的恢复进程无关的其他分片移动


{
  "restored_reports": {
    "shards": [
      {
        "id": 3,
        "type": "SNAPSHOT",					注:type表示恢复的本质;这个分片是在从一个快照恢复
        "stage": "INDEX",
        "primary": true,
        "start_time_in_millis": 1564540373531,
        "total_time_in_millis": 658566,
        "source": {							注:source哈希描述了作为恢复来源的特定快照和仓库
          "repository": "es_219_standby",
          "snapshot": "report_standby",
          "version": "5.5.1",
          "index": "reports_20190220"
        },
        "target": {
          "id": "vlp4d-CEQXSQhJ0eWdDpoQ",
          "host": "192.168.1.74",
          "transport_address": "192.168.1.74:9300",
          "ip": "192.168.1.74",
          "name": "node_74"
        },
        "index": {
          "size": {
            "total_in_bytes": 3376313133,
            "reused_in_bytes": 0,
            "recovered_in_bytes": 354191,
            "percent": "0.0%"			注:percent恢复的状态。分片目前已经恢复了0%的文件
          },
          "files": {
            "total": 116,
            "reused": 0,
            "recovered": 26,
            "percent": "22.4%"
          },
          "total_time_in_millis": 658550,
          "source_throttle_time_in_millis": 0,
          "target_throttle_time_in_millis": 0
        },
        "translog": {
          "recovered": 0,
          "total": 0,
          "percent": "100.0%",
          "total_on_start": 0,
          "total_time_in_millis": 0
        },
        "verify_index": {
          "check_index_time_in_millis": 0,
          "total_time_in_millis": 0
        }
      },
  • 取消一个恢复
DELETE /【自定义恢复的索引名称】

注:要取消一个恢复,你需要删除正在恢复的索引。 因为恢复进程其实就是分片恢复,发送一个 删除索引API 修改集群状态,就可以停止恢复进程,如果 【自定义恢复的索引名称】 正在恢复中,这个删除命令会停止恢复,同时删除所有已经恢复到集群里的数据

  • 删除快照
DELETE /_snapshot/【厂库名称】/【快照名称】
  • 查看仓库下的快照信息
GET /_snapshot/【厂库名称】/_all 
### 热冷备集群中的数据同步方法与解决方案 在热冷备集群的设计中,数据同步是一个至关重要的环节。为了确保冷节点能够在主节点失效时快速接管并提供一致性的服务,需要采取高效、稳定的数据同步策略。以下是几种常见且有效的数据同步方法及其适用场景分析: --- #### 1. **基于 CCR (Cross Cluster Replication)** 的实时数据同步 - ElasticSearch 提供了官方的跨集群复制功能——CCR[^1],能够实现实时或近实时的数据同步。 - 当前集群(即热节点)作为领导者索引,远程集群(即冷节点)作为追随者索引,任何数据变更都会被自动复制到追随者索引中。 - 此方法的优点在于配置简单、性能优越以及无需额外开发工作即可完成复杂的同步任务。 ```json // 启动 CCR 复制流程示例 PUT _ccr/follow/<target_index> { "leader_index": "<source_index>", "remote_cluster": "my_remote_cluster" } ``` 然而需要注意的是,该方案对网络环境有一定依赖性,较高的网络延迟可能会削弱其效率表现[^1]。 --- #### 2. **使用 Gobblin 实现批量 ETL 数据迁移** - 对于一些非结构化或者半结构化的海量数据集来说,可以借助 Apache 开源项目 Gobblin 来达成高效的提取、转换和加载(ETL)[^2]。 - 它特别擅长处理来自 Kafka 流的消息并将它们持久化至 HDFS 文件系统之中,非常适合定时增量更新的应用场合。 ```java // 配置 gobblin job 属性样例 job.type=incremental extractor.class=gobblin.extractor.kafka.KafkaExtractor writer.builder.class=gobblin.writer.hdfs.HDFSWriterBuilder ``` 尽管如此,由于它是批处理性质的工作负载,因此无法做到像 CCR 那样的即时响应速度[^2]。 --- #### 3. **Redis 跨机房数据同步的最佳实践** 针对内存数据库 Redis 场景下的热冷备需求,业界已探索出了多种可行的技术路线[^3]: ##### (1)**主从模式** - 最基础也是最常用的单向复制形式,由 Master 节点负责生产新数据并通过 PSYNC 协议通知 Slave 跟随修改。 - 其特点是容易理解和部署,但不具备反向传播的能力,仅适合简单的只读扩展用途。 ##### (2)**代理模式** - 引入中间件充当桥梁角色,在接收到来自客户端的写指令后分别转发给多个远端实例保存副本。 - 这种架构灵活性较强,不过同时也带来了更高的管理难度和技术门槛要求。 ##### (3)**多活-AOF 日志同步** - 基于 Append Only File(AOF) 记录每一次操作命令序列号的形式来进行精确重播恢复。 - 尽管具备极高的可靠性保障级别,但由于涉及到大量的磁盘 IO 操作所以总体耗时较长成本较大。 ```bash # 设置 redis AOF 功能开启参数 appendonly yes aof-load-truncated yes ``` 无论选用哪一种具体的实现路径都需要充分考虑到诸如防循环复制机制设计、数据一致性校验算法选取以及必要的性能调优措施等因素影响最终效果的好坏程度。 --- ### 总结 综上所述,不同类型的业务诉求往往决定了最适合自己的那套数据同步办法。如果是追求极致时效性的在线检索类应用推荐优先考察 CCR 技术栈;而对于离线数据分析挖掘领域则不妨尝试一下依托 Gobblin 构建起来的大规模流水生产线程模型;至于那些高度关注事务完整性的关键交易记录保护作业,则务必慎重权衡各类 Redis 同步变体间的利弊关系再做定夺! ---
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值