Milvus数据迁移和版本升级遇到问题，

[carrison]

方案如下：

1. 将数据volumes目录从源主机/data/volumes scp到目标服务器/data/volumes（复制目录时源主机未停milvus-standalone容器，milvus版本2.5.8）
2. 目标服务器上执行/data/standalone_embed_latest.sh upgrade(目标服务器上milvus原来版本是2.6.0)，成功升级milvus到v2.6.9
   CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
   aefa147b5e48 milvusdb/milvus:v2.6.9 "/tini -- milvus run…" 13 hours ago Up 13 hours (healthy) 0.0.0.0:2379->2379/tcp, :::2379->2379/tcp, 0.0.0.0:9091->9091/tcp, :::9091->9091/tcp, 0.0.0.0:19530->19530/tcp, :::19530->19530/tcp milvus-standalone
3. 发现问题：
   在源主机上执行python脚本，显示集合数正常
   python3 aaa.py
   当前集合数量: 65223
   集合列表: ['open_webui_file_91c51b1e_8223_49a6_a7fa_05e0e081b978', 'open_webui_file_7b05578a_c932_4ecc_8bc4_3aa5f0394d0b', 'open_webui_file_67ce1b93_80bc_494e_b96a_c5351da1dac4', 'open_webui_file_fd744721_b2b8_4a19_8958_b243daa6c8f2', 'open_webui_file_0c47ec4c_0a8e_4d9d_a609_015ed1f56c8d', 'open_webui_file_60da1b6b_d822_43ab_adad_810faa4b6a47', 'open_webui_file_5749e54d_2470_41bc_af1b_347a028d7a61', 'open_webui_file_a80d105f_3e9e_45dd_90d4_71b310fe8a37', 'open_webui_file_3f80fef0_e6dc_4e03_87b1_65953ed0c48e', 'open_webui_file_b2caa8e7_ba6a_4e11_b90a_fb224e61c6f1']
   ... ...
   cat aaa.py
   from pymilvus import connections, utility
   connections.connect(
   alias='default',
   host='localhost',
   port='19530',
   user='root',
   password='passWord8',
   )
   #utility.reset_password('root', 'Milvus', 'e57EmszV5D', using='default')
   collections = utility.list_collections()
   print(f"当前集合数量: {len(collections)}")
   print("集合列表:", collections[:10]) # 查看前10个

在目标服务器上执行aaa.py显示如下：
python3 aaa.py
当前集合数量: 0
集合列表: []
不知道哪里出的问题，目前怀疑两点：

1. 源主机复制volumes目录时未停容器
2. 版本直接升级，从v2.5.8到v2.6.9，是不是应该v2.5.8-->2.5.25-->2.6.9?

[carrison]

重新v2.5.8-->2.5.25后，集合显示正常

[carrison]

python3 aaa.py
当前集合数量: 65223
集合列表: ['open_webui_file_a71273d4_dc5d_417f_867c_b39e13c1d468', 'open_webui_file_de4be086_2d50_4ced_984b_0790b7b2388a', 'open_webui_file_6c155447_71bf_4528_b409_0b524adb0f6a', 'open_webui_file_ea5b27d3_990a_45f6_af24_9645b9a57325', 'open_webui_file_2b43b541_5d35_4dd9_a4cc_77585d0d4dd1', 'open_webui_file_5619879e_404f_4a50_b162_22e163417806', 'open_webui_file_6fe2c9e8_35a3_4da8_b87b_b7f7135d5862', 'open_webui_file_38a8eedb_a16e_4382_8d41_7cf0386690b8', 'open_webui_file_19f321d0_36cf_4cc7_a754_2eac442e13c1', 'open_webui_file_884b458d_2f6a_45bd_8370_a157884fb538']

[yhmo]

copy volumes时最好是把source server停止。volumes里有etcd目录，minio目录。etcd目录类似于账本，minio目录类似于金库，milvus类似于银行。当银行收到一笔黄金时，先把黄金搬进金库，然后在账本上记上一笔。在milvus运行期间，后台经常会做这种入库和记账本的动作，copy volmes时并不是一瞬间就能拷贝完成，而是持续一段时间，很可能造成拷贝的etcd目录和minio目录里的东西不一致，就好比金库里存的黄金和账本上记的帐不一致。

升级以下面的步骤走是正确的：
v2.5.8-->2.5.25-->2.6.9

[carrison]

多谢，我重新迁移v2.5.8-->2.5.25-->2.6.9试试

[carrison]

请推荐一款milvus迁移工具，刚刚试了milvus-backup，比较难用

[yhmo]

如果是自己写迁移逻辑的话，只能靠query_iterator了
大致是这样：

    # declare two milvus clients
    client1 = MilvusClient(uri=URI_1)
    client2 = MilvusClient(uri=URI_2)

    # create a new collection in client 2
    client2.create_collection(collection_name="BBB",
                              schema=schema,
                              )
    # set this property so that auto-id primary key can be inserted
    client2.alter_collection_properties(
        collection_name="BBB",
        properties={"allow_insert_auto_id": "true"}
    )

    # iterator from client 1
    iterator = client1.query_iterator(collection_name="AAA", output_fields=["*"])
    while True:
        res = iterator.next()
        if len(res) == 0:
            print("query iteration finished, close")
            iterator.close()
            break

        # insert the data into client 2
        client2.insert(collection_name="BBB", data=res)

[xiaofan-luan]

backup是最简单的方式，zilliz cloud也会有backup 工具。
也可以考虑用vts

[carrison]

找到失败的原因了。我从测试环境scp生产环境volumes目录时，volumes/milvus/etcd这个目录复制失败，完成复制后就正常升级了