一.reindex
elasticsearch提供的一种复制索引的API。可以在集群内进行索引的复制,也可以跨集群进行索引的复制。
操作方式:
代码语言:javascript复制#不携带任何参数,将my-index索引的数据复制到new-index中。
POST _reindex
{
"source": {
"index": "my-index"#源索引
},
"dest": {
"index": "new-index"#目的索引
}
}
#指定match查询,只同步在源索引的查询结果至目的索引中。同时对目的索引的路由进行了设置。
POST _reindex
{
"source": {
"index": "source-index",
"query": {
"match": {
"company": "cat"
}
}
},
"dest": {
"index": "dest-index",
"routing": "=cat"
}
}
应用场景:
- 索引迁移或重建:reindex API 可以帮助将数据从一个索引移动到另一个索引,例如在索引结构发生变化或需要重建索引时。
- 数据清洗和转换:reindex API 可以通过在重建过程中应用过滤器和转换操作,对数据进行清洗和转换。
- 索引合并:reindex API 可以将多个索引中的数据合并到一个新的索引中,以简化数据的管理和查询。
- 数据备份和恢复:reindex API 可以用于创建索引的备份,并在需要时将数据恢复到原始或新的索引中。
优点:
- 简单易用:在我们对索引进行重建或迁移时,reindex提供了简单的语法和参数,使数据迁移的操作更加便捷。
- 高效性能:当我们不指定任何参数时,reindex在elasticsearch内部执行时会使用并行处理与批量操作,以提高reindex的效率。
- 灵活性:reindex 可以搭配查询语句,过滤器,数据转换条件等配置,更好的满足我们数据迁移与重建的需求。。
- 可靠性:我们在通过reindex进行大数据量的索引迁移时,reindex自带了错误处理与任务重试机制,当reindex的过程中遇到错误,reindex会自动进行回滚,并重新从异常位置继续复制数据。
缺点:
- 资源消耗:reindex在进行大数据量级的索引复制或重建时,可能会长时间占用系统资源,例如CPU,磁盘IO等。
- 网络带宽:如果我们是进行跨集群的数据复制迁移,当迁移索引的数据量过大时,可能会长时间大量占用网络带宽。
- 索引锁定:为了保证迁移前后的数据一致,在进行reindex时,我们一般会将源索引置为只读。如果我们需要对源索引与目的索引进行一些操作时,可能会导致操作的延迟或阻塞。
使用建议:
- 为了保证迁移前后,源索引与目的索引的数据量一致,我们需要将源索引设置为只读,同时目的索引除reindex操作之外,不能有其他的数据对其进行写入。
- 在reindex时,我们可以对目的索引先不配置副本,这样避免目的索引初始化副本分片,延长reindex时间,可以提高reindex的速度,等reindex完成后,在进行副本的添加操作。
- 进行reindex时,不建议对操作进行资源使用的约束。避免当多个reindex任务进行时,造成资源争抢,例如:限制任务切片slices,能够调用的CPU核数等。
二.CCR
全称"cross cluster Replication",CCR是elasticsearch提供的一种将一个集群的数据实时的复制到另一个集群的功能,也称为跨集群复制。需要在elasticsearch中配置remote cluster(远端集群)。CCR使用的是追随者模式,在使用CCR时,首先我们需要将elasticsearch集群分别划分为leader集群和follower集群。同时对索引也需要进行指定leader索引与follower索引。
操作方式:
代码语言:javascript复制#设置远端集群
PUT _cluster/settings
{
"persistent": {
"cluster": {
"remote": {
"cluster_one": {
"seeds": [
"127.0.0.1:9300"
]
},
"cluster_two": {
"mode": "sniff",
"seeds": [
"127.0.0.1:9301"
],
"transport.compress": true,
"skip_unavailable": true
},
"cluster_three": {
"mode": "proxy",
"proxy_address": "127.0.0.1:9302"
}
}
}
}
}
#在CCR中指定远端集群的角色为leader,并设置需要同步哪些索引
PUT /_ccr/auto_follow/beats
{
"remote_cluster" : "leader",
"leader_index_patterns" :
[
"metricbeat-*",
"packetbeat-*"
],
"follow_index_pattern" : "{{leader_index}}-copy"
}
应用场景:
- 灾难恢复:使用CCR在两个或多几个集群之间跨集群复制数据后,可以避免某个集群由于故障导致服务不可用,防止数据丢失。
- 数据备份:通过跨集群复制的方式,可以定时将一个集群的数据复制到另一个集群,自动完成数据备份操作。避免人工进行数据备份。
- 数据共享:通过跨集群复制的这种方式,可以实时共享一个数据的集群到另一个集群,便于多个集群之间访问相同的数据。
- 数据迁移:可以实时将数据从一个集群复制到另一个集群,复制完成后,即可解除追随者模式,完成数据迁移。
优点:
- 高效可靠:CCR使用的是 elasticsearch的snapshot功能,可以保证数据的安全性和完整性。
- 灵活可扩展:CCR可以根据需要扩展到多个集群,并可以根据需要调整复制频率。
缺点:
- 复杂性:跨集群复制在使用之前的学习成本较高,配置和管理相对比较复杂。
- 网络延迟:跨集群复制十分依赖集群间的网络环境,如果两个集群之间的网络延迟较大,则可能会影响数据复制速度。
三.COS快照
cos快照这里主要使用的是elasticsearch的snapshot功能,通过在对象存储中创建仓库,将elasticsearch集群中的数据备份至对象存储系统中,实现数据的备份。同时还可以将对象存储系统中的快照恢复至其他集群。
操作方式:
代码语言:javascript复制#在对象存储中创建一个仓库。如果使用云厂商的对象存储服务,则根据各云厂商的API进行仓库的创建。
PUT /_snapshot/my_repository
{
"type": "fs",
"settings": {
"location": "my_backup_location"
}
}
#在名为my_repository仓库中创建一个名为my_snapshot的快照
PUT /_snapshot/my_repository/my_snapshot
#对index_1,index_2进行备份
PUT /_snapshot/my_repository/snapshot_2?wait_for_completion=true
{
"indices": "index_1,index_2",
"ignore_unavailable": true,
"include_global_state": false,
"metadata": {
"taken_by": "user123",
"taken_because": "backup before upgrading"
}
}
#指定快照进行恢复
POST /_snapshot/my_repository/my_snapshot/_restore
应用场景:
- 数据恢复:如果我们之前对elasticsearch集群的索引数据有进行cos快照备份,在集群数据发生丢失时,可以基于快照备份的时间节点,使用snapshot恢复指定快照的数据至集群。
- 数据备份:可以使用 snapshot 定期备份数据。
- 数据迁移:可以使用 snapshot 将数据从一个集群迁移到另一个集群,源集群与目的集群必须使用同一个快照仓库,才能够读取到相应的快照。
优点:
- 简单易用:我们前期只需要创建好snapshot仓库就可以了。后期只需要执行创建快照并备份的API就可以了。整体使用简单便捷。
- 灵活扩展:通过snapshot快照备份与恢复机制,我们可以将一个集群的数据快速恢复至多个集群。
缺点:
- 需要额外的资源:创建和恢复 snapshot 需要使用对象存储中的资源,包括 CPU、内存和磁盘空间。
- 网络延迟:snapshot快照存储的数据都在远端对象存储系统中,如果网络环境较差,对于快照的备份与恢复则都会有影响。
我正在参与2023腾讯技术创作特训营第三期有奖征文,组队打卡瓜分大奖!