2

我对 python 和boto提供的 S3/Glacier 集成接口都很陌生。然而，我发现了几个似乎特别没有记录/未解决的缺陷，这些缺陷严重阻碍了我当前工作项目的进展。

我最近的困境与库中的restore()功能有关boto。很简单，它根本不起作用。一段时间以来，我怀疑该问题与Key对象在跟踪storage_class存储在 S3 存储桶中的数据不一致的问题有关。这个页面可以是关于该问题的一些细节的资源：https ://github.com/boto/boto/issues/1173

要详细说明Key一致性问题，请考虑以下有关已从 S3 归档到 Glacier 的对象的场景：

from boto.s3.connection import S3Connection
from boto.s3.key import Key
...
conn = S3Connection(access_key_id, secret_key)
bucket = conn.get_bucket(bucket_name)
key_object = Key(bucket)

print bucket.get_key(filename).storage_class
...
key_object.key = filename
for item in bucket.list():
    if item.key == filename:
        break

print item.storage_class

一些澄清。我知道for在存储桶中搜索密钥的循环效率非常低，但这正是其中的奥秘。

第一条print语句将产生：u'STANDARD'

第二：u'GLACIER'

现在向前看，我相信这种不一致正在影响restore()操作的效果。如果我尝试key.restore(days=num_days)使用上面列出的任一“关键”派生，它们都没有表明它将对象从 Glacier 恢复到标准 S3 可访问性有任何影响。此外，尝试restore返回None. 在这一点上，我完全不知道什么可以解释这个故障。这是我的程序错误吗？还是有什么与生俱来的坏事boto？

您能为我提供的任何帮助将不胜感激。

谢谢你。

注意：我没有忘记基本的错误检查，即文件是否存在于存储桶中？文件已经恢复了吗？等等

4

2 回答 2

1

如果您已经在跟踪文件名，您是否尝试过通过http://docs.pythonboto.org/en/latest/s3_tut.html#transitioning-objects-to-glacier遵循文档的示例

conn = S3Connection(access_key_id, secret_key)
bucket = conn.get_bucket(bucket_name)
key = bucket.get_key(filename)
key.restore(days=5)

使用 key.ongoing_restore 获取恢复状态

于 2014-04-28T00:31:07.940 回答
1

我弄清楚我的困惑是什么。一旦一个物体在 Glacier 上，它就会留在 Glacier 上。它可以恢复以便可以下载，但它的存储类永远不会从 Glacier 更改回 S3 标准（为此，您必须制作对象的副本并确保该副本位于标准存储中）。

密钥不一致仍然是一个问题，但我找到了一些解决方法（我最好避免，但目前我别无选择）。

于 2014-05-01T14:17:40.457 回答