分片集群平滑迁移实验(成功) 过程概述: 为每个分片添加多个从节点,然后自动同步。同步完后,切换主节点到新服务器节点。 老服务器的三分片数据 迁移到 新服务器的三片集群 老分片环境: 192.168.168.56 22001 22002 22003 192.168.168.57 22001 22002 22003 192.168.168.58 shard2/log/shard2.log --fork --oplogSize 10000 /usr/local/mongodb/bin/mongod--shardsvr --replSet shard3 --port 22003 --dbpath /data/mongodb/shard3/data--logpath /data/mongodb/shard3/log/shard3.log --fork - 分片集群平滑迁移成功 #备注# config服务器需要替换成新的服务器ip地址和端口 /usr/local/mongodb/bin/mongos--configdb 192.168.6.103:21000,192.168.6.104
一.物理导入 简介 redis集群在存储数据时,是根据槽点进行存储。例如老集群A如下: 都在一台机器,实际可以在多台机器上。 实际操作 老集群:1.1.1.1 主节点:7000(0-5460) 7001(5461-10922) 7002(10923-16383) 从节点:7003 7004 7005 新集群:1.1.1.2 主节点 :6000(0-3000) 6001(3001-5460) 6002(5461-10922) 6003(10923-16383) 从节点:6004 6005 6006 6007 可以发现新集群的节点多了一个 将老集群的7000节点的appendonly.aof用pipe方法导入到6000节点上。再将同文件导入到6001节点上。
背景 velero 是备份和还原kubernetes集群资源的和持久卷的工具, 主要提供了以下功能: 备份还原集群 不同集群间进行迁移 集群复制 tke官方文档中以及有了velero的最佳实践(https ://cloud.tencent.com/document/product/457/50122),本篇文章是在原官方文档中内的补充,针对velero-plugin-for-tencent 插件的使用. cos正常:velero backup-location get [image.png] 备份 测试场景从A集群迁移到B集群 备份A集群 velero backup create cluster-a - kubeconfig文件避免部署到原来的集群中(--kubeconfig 参数) 迁移命令: velero restore create cluster-b --from-backup cluster-a logs <BACKUP-NAME> | grep skip 验证 使用一下命令查看迁移过后的集群应用信息: kubectl get po --all-namespace 如果部分有问题,需要进步排查
r etcdv2.zip /opt/etcdv2 传送至新节点: scp etcdv2.zip root@xxxx:/opt # scp至新机器(一台机器即可,这里传到了new-01节点上) 新集群恢复 unzip /opt/etcdv2 && mv /opt/etcdv2/member /var/lib/etcd/infra1.etcd/ 2.启动新节点(new-01节点) 因为备份的数据中,存在旧服务的集群信息 ,因为我们进行了迁移,需要将原本的集群信息覆盖掉(不影响用户数据),启动参数中添加配置--force-new-cluster,等服务成功启动后,旧集群信息已被覆盖,然后去掉此配置,重启服务即可 注:节点配置中 3.修正当前节点的peerURLs 在迁移过程中,出现了当前节点的peerURLs错误的问题,需要修正下 查看节点信息: [root@prod-k8s-01 ~]# etcdctl member list prod-k8s-01 ~]# etcdctl member update 76926a56d901 http://10.94.19.179:2380 # 更改节点peerurls 至此,我们已经成功在新集群恢复了旧集群的数据
RabbitMQ 集群数据迁移,完成集群A 到集群B 的数据迁移。 RabbitMQ 官网有这么一段话: ? 因此集群消息迁移的思路,是备份这些文件夹。 然后还有一段话 ? 大致意思是在恢复数据前,要先恢复元数据。 测试过程: 集群A: ? 集群A 队列消息: ? 集群B: ? 没有任何消息,队列。 数据恢复如下: 1.导出集群A 的元数据。rabbit_n1_2020-3-30.json ? 2. 将集群A的元数据导入到集群B ? ? 3. 停掉集群B ,将 集群A 的 n1 n2 n3 的文件,分别拷贝到 集群B 的 n1 n2 n3 文件mnesia 目录下。 5. 这样就完成了RabbitMQ集群数据迁移。
5.0版本 微软云elasticsearch集群5.6版本 需求 需要把阿里云elasticsearch集群新老数据迁移到微软云elasticsearch集群 解决 新数据比较好弄数据源输出到新的微软云 kafka集群然后微软云logstash消费新数据到新elasticsearch集群即可,关于老数据迁移比较麻烦,但官网也给了成熟的解决方案既是快照备份与还原,下面实施过程既是对实施过程的记录 实施 阿里云 elasticsearch集群操作 一,先关闭数据平衡,注意一个一个的来,关一个节点的进程none,all循环一次,否则最后集群切片变动,恢复时间很长 1、修改elasticsearch.yml配置,添加如下 4操作在剩下几个节点,最好通过/_cat/health查看集群恢复100%后操作下一次,如果不关闭allocation重启elasticsearch集群恢复时间很长会从0%开始,关闭后从节点数减一除以总节点数比例开始恢复会块很多 在微软云elasticsearch集群上操作 四、迁移数据到微软云elasticsearch集群 1、挂载nfs服务端 yum -y install nfs-utils mkdir -p /storage
跨集群数据迁移 用户在腾讯云上自建的ES集群或者在其它云厂商购买的ES集群,如果要迁移至腾讯云ES,用户可以根据自己的业务需要选择适合自己的迁移方案。 --limit:每次向目标ES集群写入数据的条数,不可设置的过大,以免bulk队列写满 3 . AWS S3对象存储,快照存放于S3中,以插件形式支持 hdfs: 快照存放于hdfs中,以插件形式支持 cos: 快照存放于腾讯云COS对象存储中,以插件形式支持 如果需要从自建ES集群迁移至腾讯云的 ES集群,或者腾讯云内部的ES集群迁移,可以使用对应云厂商他提供的仓库类型,如AWS的S3, 阿里云的OSS,腾讯云的COS等 curl -XPUT http://172.16.0.39:9200/ _snapshot/my_s3_repository { "type": "s3", "settings": { "bucket": "my_bucket_name"
本方案旨在通过集群融合的方式帮助用户进行在线迁移,尽量降低迁移过程对业务的影响,同时尽可能提高迁移的自动化程度。 二、整体思路 假定用户原有集群为A,迁移后新集群为B。 首先通过扩容的方式把集群B融合进集群A;然后通过ES的自动搬迁能力,把所有集群A的数据迁移到集群B;最后用户下线集群A即可。 四、 集群融合步骤 首先假设迁移过程中涉及的集群信息如下: 用户集群 :用户原有自建的集群,假定cluster_name为 es_A。 新建集群 : 云上新建的集群,假定cluster_name为 es_B。 具体迁移操作步骤如下: 1、融合前,对 新建集群 需要确认没有打开权限,如果有打开,需要关闭。 "es_config": { "cluster.name": "es_A" }, "restart_type": "full_cluster_restart" 3、
本方案旨在通过集群融合的方式帮助用户进行在线迁移,尽量降低迁移过程对业务的影响,同时尽可能提高迁移的自动化程度。 二、整体思路 假定用户原有集群为A,迁移后新集群为B。 首先通过扩容的方式把集群B融合进集群A;然后通过ES的自动搬迁能力,把所有集群A的数据迁移到集群B;最后用户下线集群A即可。 四、 集群融合步骤 首先假设迁移过程中涉及的集群信息如下: 用户集群 :用户原有自建的集群,假定cluster_name为 es_A。 新建集群 : 云上新建的集群,假定cluster_name为 es_B。 具体迁移操作步骤如下: 1、融合前,对 新建集群 需要确认没有打开权限,如果有打开,需要关闭。 "es_config": { "cluster.name": "es_A" }, "restart_type": "full_cluster_restart" 3、
场景介绍:在我们的IDC中,存在着运行了3-6年的Ceph集群的服务器,这些服务器性能和容量等都已经无法满足当前业务的需求,在购入一批高性能机器后,希望将旧机器上的集群整体迁移到新机器上,当然,是保证业务不中断的前提下 ,各个组件分布如下,也就是说,将运行于 con,com,ceph三个节点的 Ceph 集群迁移到 new_mon_1,new_mon_2,new_mon_3 这三台新机器上。 叫做 new_tree),这样部署完毕后,不会对原有集群有任何影响,也不会涉及到数据迁移的问题,此时新的OSD下还没有保存数据。 添加完这三个OSD后,集群总共有六个OSD,此时不会有数据迁移。 集群性能降低:总体来说,在副本从2克隆为4这段时间(约2-3天,取决于集群数据量)内,集群的实际IO表现降低到变更前的 25%->80% 左右,时间越往后表现越接近变更前,这虽然不会导致客户端的IO阻塞
场景介绍:在我们的IDC中,存在着运行了3-6年的Ceph集群的服务器,这些服务器性能和容量等都已经无法满足当前业务的需求,在购入一批高性能机器后,希望将旧机器上的集群整体迁移到新机器上,当然,是保证业务不中断的前提下 ,各个组件分布如下,也就是说,将运行于 con,com,ceph三个节点的 Ceph 集群迁移到 new_mon_1,new_mon_2,new_mon_3 这三台新机器上。 叫做 new_tree),这样部署完毕后,不会对原有集群有任何影响,也不会涉及到数据迁移的问题,此时新的OSD下还没有保存数据。 添加完这三个OSD后,集群总共有六个OSD,此时不会有数据迁移。 集群性能降低:总体来说,在副本从2克隆为4这段时间(约2-3天,取决于集群数据量)内,集群的实际IO表现降低到变更前的 25%->80% 左右,时间越往后表现越接近变更前,这虽然不会导致客户端的IO阻塞
注意:此方案为非实时同步方案,但借助 MinIO 客户端的数据同步功能,应该也是可以做到实时同步迁移。 制作 milvus-backup 镜像 注意:如果是在两个单机版的 milvus 之间迁移数据,是不需要 milvus-backup 镜像的,又或者,如果 k8s 集群部署了 milvus, minio 注意一下,由于需要在两个集群间迁移,因此创建工作负载的时候挂载一个共享存储(/backup),方便迁移 MinIO 备份后的数据。 03. : address: localhost # Address of MinIO/S3 ... 恢复数据到新的集群中 进入新的集群(B)执行步骤 2和步骤 3,在步骤 3 中将 backup.yaml 中的配置修改成集群 B 的链接信息。
# 现集群中有3个 follower zk_synced_followers 3 # 已同步的 follower 节点数 zk_pending_syncs 0 zk_last_proposal_size /zkServer.sh restart 然后登录新集群的 leader 节点,动态移除旧集群的最后一个节点 ./zkCli.sh reconfig -remove 3 停止旧集群最后一个节点服务 . 0.0.0.0:2181 server.6=172.16.20.250:2888:3888:participant;0.0.0.0:2181 version=300000003 至此,zookeeper 集群迁移完毕 pulsar迁移zookeeper时,zookeeper中的元数据保存的还是以前pulsar初始化时的老的zookeeper地址,否则会报无法连到zookeeper . /zkCli.sh -server 127.0.0.1:12181 set /pulsar/functions '复制上面输出的内容,并改成新的zookeeper地址,大概有3行 '
简介 根据业务需求,存在以下场景: 迁移过程中,旧的集群可以暂时停止服务或者暂停写入,数据全部迁移到新的集群中后,业务切换到新的集群进行读取和写入 迁移过程中,旧集群不能停止写入,业务不能停服 如果是第一种场景 AWS S3对象存储,快照存放于S3中,以插件形式支持 hdfs: 快照存放于hdfs中,以插件形式支持 cos: 快照存放于腾讯云COS对象存储中,以插件形式支持 如果需要从自建ES集群迁移至腾讯云的 ES集群,或者腾讯云内部的ES集群迁移,可以使用对应云厂商他提供的仓库类型,如AWS的S3, 阿里云的OSS,腾讯云的COS等 curl -XPUT http://172.16.0.39:9200/_snapshot } } POST _search/scroll { "scroll": "1m", "scroll_id": "DnF1ZXJ5VGhlbkZldGNoBQAAAAAAHCbaFndPR3J4bDJtVDh1bnNRaW5yYWZBWncAAAAAABwm2RZ3T0dyeGwybVQ4dW5zUWlucmFmQVp3AAAAAAAcJtwWd09HcnhsMm1UOHVuc1FpbnJhZkFadwAAAAAAHCbbFndPR3J4bDJtVDh1bnNRaW5yYWZBWncAAAAAABwm3RZ3T0dyeGwybVQ4dW5zUWlucmFmQVp3 add & update & delete 如果业务写入ES时既有新增(add)数据,又有更新(update)和删除(delete)数据,可以采用6.5之后商业版X-pack插件中的CCR功能进行数据迁移
在工作中可能会遇到这样的场景,即需要把一个Jenkins Master上的job迁移到另外一台Jenkins Master上,那怎么做比较好呢? 那我们现在来介绍下这种配置项较多、job比较多的情况下怎么来迁移这些job。 现在我搭建了两台Jenkins来进行说明。 Job Import Plugin导入 现在先介绍第一种方式,通过Job Import Plugin方式来进行job的迁移,这种方式比较方便,首先到新的Jenkins上,也就是192.168.9.8上, 在192.168.9.8上插件管理里先安装下Job Import Plugin,如下所示: 安装完后进入“Manage Jenkins” -> “Configure System”下,找到Job Import Jenkins上的插件新Jenkins上未必有,因此可以根据实际情况勾选是否需要安装必要的插件,如上面的截图所示,需不需要覆盖已有的job也根据实际情况勾选下。
192.168.1.185的6379 目标 192.168.1.91的7001,7002 192.168.1.92的7003,7004 192.168.1.94的7005,7006 2.准备存储文件 在集群任意节点上查看节点信息 数据恢复到集群 切换到192.168.1.91上查看集群状态 redis-trib.rb check 192.168.1.91:7001 image.png 从刚才的集群状态得知 192.168.1.91 f2ebf72a78f2637eead82c219f2fca737a36a371 ,其有 5461 个slots 192.168.1.92:7005 的runid为 99439ae72385633d3c9530a5e4f2afdca22a3e25 --slots 5461 --yes 192.168.1.91:7001 将94的slots移动到91上 redis-trib.rb reshard --from 99439ae72385633d3c9530a5e4f2afdca22a3e25 slots移动到94上 redis-trib.rb reshard --from f2ebf72a78f2637eead82c219f2fca737a36a371 --to 99439ae72385633d3c9530a5e4f2afdca22a3e25
//web_services; proxy_connect_timeout 2s; proxy_read_timeout 3s 50x.html; location = /50x.html { root html; } } 其中proxy_read_timeout 3s 指的是当响应超过3秒后,会重新负载到新的Server上去,在我们这里就是9090无法响应,3秒后会负载到8080端口上去,并默认在10秒后才会重新访问9090端口,以此循环。
工作中有时会遇到需要把原Redis集群下线,迁移到另一个新的Redis集群的需求(如机房迁移,Redis上云等原因)。此时原Redis中的数据需要如何操作才可顺利迁移到一个新的Redis集群呢? image.png Redis-Cluster迁移 方法一: 集群节点增删实现 方法1: 集群节点增删实现 把Redis新节点逐台加入当前集群,变成一个大的Redis集群。 若场景是希望原Redis集群暂时保留,即如下图,同时有两个独立的集群,则就无法使用迁移方法1。 如果目的端是集群模式,可以写入到一个结点,然后再进行slot的迁移,当然也可以多对多写入。 环境准备 本文进行Redis集群迁移测试,为了节约机器,目标集群复用了源Redis机器,只是修改了端口。 [OK] 3 keys in 3 masters.
需求背景 将阿里云同一个VPC下的RabbitMQ集群的消息从一个网段集群迁移到另一个网段集群。消息中间件的消息是即时消费,为何还有历史消息,因为是历史遗留问题。 Listing queues for vhost / ... queue_test_3 100000 queue_test_2 200 queue_test_1 10000 迁移方案 迁移步骤 1. 将集群B中的机器依次一台一台加入集群A中,并确认所有队列镜像完成 3. 剔除集群A中的一台一台机器 4. 方案2【可行】 若RabbitMQ采用镜像队列,将集群A中的消息数据迁移到集群B中, 集群A中的node171、node172采用镜像队列 构建集群A的镜像队列环境 1.首先集群A中的node172加入集群中
02 — 迁移前准备 在目标集群中创建好hadoop大数据环境(hive/hbase/hadoop) 在目前集群中安装部署好kylin环境,确保kylin可以正常启动并build cube任务 双方网络互通 ,大数据拉取数据端口开放,可以正常拉取到源集群中的hdfs文件 目前集群的kylin版本与源集群版本保持一致 确保在目标集群中hive表已经构建且数据已经迁移完成 提前准备好数据迁移的脚本,hdfs数据迁移 Kylin元数据迁移的方案制定 一、方案一 通过元数据备份/还原的方式实现两个集群的元数据同步 二、方案二 通过kylin自己的工具将cube导出然后在另外集群导入方式进行元数据同步 三、方案三 将kylin 在hbase上存储的metadata表数据迁移,实现元数据同步 Kylin cube预计算数据迁移方案: 通过hbase的snapshot方式在另外一个集群恢复实现 04 — 迁移前的前置依赖 在进行 问题六: 在使用hdfs倒过来的目录和文件的用户权限依旧是源集群中的用户权限.会导致kylin 在step1的时候build异常 解决方法: 在源集群中迁移过来的目录和文件,需要在目标集群中修改用户以及用户的权限