zilliztech/milvus-backup

[Bug]: milvus-backup v0.3.3 in Milvus v2.2.11 standalone uses Docker. only restore schema but data is empty

631068264 opened this issue · 4 comments

631068264 commented

Current Behavior

On machine A standalone uses Docker.

./milvus-backup create -n my_backup

On machine B standalone uses Docker.

./milvus-backup restore -n my_backup

Milvus on B collections are empty but I has data on A . logs on two machine didn't has any error.

some logs on B

[2024/04/09 16:24:38.850 +08:00] [INFO] [core/backup_impl_restore_backup.go:451] ["create partition"] [collectionName=bge_title_content_test] [partitionName=_default_17]
[2024/04/09 16:24:38.850 +08:00] [INFO] [core/backup_impl_restore_backup.go:625] [getBackupPartitionPaths] [bucketName=a-bucket] [backupPath=backup/bge_title_content_test] [partitionID=447241249106717923]
[2024/04/09 16:24:38.863 +08:00] [INFO] [core/backup_impl_restore_backup.go:593] ["bulkinsert task state"] [id=448960154939969666] [state=2] [state="{\"ID\":448960154939969666,\"State\":2,\"RowCount\":0,\"IDList\":null,\"Infos\":{\"backup\":\"true\",\"collection\":\"bge_title_content_test\",\"end_ts\":\"448961139441664\",\"failed_reason\":\"\",\"files\":\"backup/bge_title_content_test/binlogs/insert_log/447241249106717905/447241249106717923/,\",\"partition\":\"_default_17\"},\"CollectionID\":448960154939969582,\"SegmentIDs\":null,\"CreateTs\":1712651078}"] [progress=0] [currentTimestamp=1712651078] [lastUpdateTime=1712651078]
[2024/04/09 16:24:43.870 +08:00] [INFO] [core/backup_impl_restore_backup.go:593] ["bulkinsert task state"] [id=448960154939969666] [state=6] [state="{\"ID\":448960154939969666,\"State\":6,\"RowCount\":0,\"IDList\":null,\"Infos\":{\"backup\":\"true\",\"collection\":\"bge_title_content_test\",\"end_ts\":\"448961139441664\",\"failed_reason\":\"\",\"files\":\"backup/bge_title_content_test/binlogs/insert_log/447241249106717905/447241249106717923/,\",\"partition\":\"_default_17\",\"persist_cost\":\"0.00\",\"progress_percent\":\"100\"},\"CollectionID\":448960154939969582,\"SegmentIDs\":null,\"CreateTs\":1712651078}"] [progress=100] [currentTimestamp=1712651083] [lastUpdateTime=1712651078]
[2024/04/09 16:24:43.872 +08:00] [INFO] [core/backup_impl_restore_backup.go:451] ["create partition"] [collectionName=bge_title_content_test] [partitionName=_default_18]
[2024/04/09 16:24:43.874 +08:00] [INFO] [core/backup_impl_restore_backup.go:451] ["create partition"] [collectionName=bge_title_content_test] [partitionName=_default_19]
[2024/04/09 16:24:43.876 +08:00] [INFO] [core/backup_impl_restore_backup.go:451] ["create partition"] [collectionName=bge_title_content_test] [partitionName=_default_20]
[2024/04/09 16:24:43.878 +08:00] [INFO] [core/backup_impl_restore_backup.go:451] ["create partition"] [collectionName=bge_title_content_test] [partitionName=_default_21]

On A log
backup.log

On B log
backup.log

verify_data

def del_milvus(collection_name=None):
    connections.connect(host='localhost', port='32008')

    client = MilvusClient(
        uri="http://localhost:32008",
    )

    old_ = client.list_collections()
    for c in old_:
        collection = Collection(c)
        print({
            # "schema": collection.schema,
            "is_empty": collection.is_empty,
            "num_entities": collection.num_entities,
            "name": collection.name,
        })

only get this

{'is_empty': True, 'num_entities': 0, 'name': 'xxxx'}
{'is_empty': True, 'num_entities': 0, 'name': 'xx'}
{'is_empty': True, 'num_entities': 0, 'name': 'xxxxx'}
......

Expected Behavior

No response

Steps To Reproduce

No response

Environment

No response

Anything else?

No response

4-Struggle commented

Why not use according to the version recommended by the official website?BackUp v0.2.1ORv0.2.2

631068264 commented

Why not use according to the version recommended by the official website?BackUp v0.2.1ORv0.2.2

Because I use Milvus v2.2.11 @4-Struggle

image

Why use milvus-backup v0.2.1 OR v0.2.2 ?

4-Struggle commented

Sorry, that's my question up there. As A user, I personally feel that the corresponding troubleshooting idea is to first confirm that the corresponding image version of machine A and machine B is the same, and finally confirm the corresponding backup version. Then try a different version of the backup

631068264 commented

Sorry, that's my question up there. As A user, I personally feel that the corresponding troubleshooting idea is to first confirm that the corresponding image version of machine A and machine B is the same, and finally confirm the corresponding backup version. Then try a different version of the backup

I have tried 0.4+ but not work when I'm in trouble and I have given up using this tool