删除后存储桶名称似乎仍在使用中答案

【问题标题】：Bucket name seems to still be in use after deleting it删除后存储桶名称似乎仍在使用中
【发布时间】：2017-03-26 11:32:06
【问题描述】：

使用 Java S3 SDK，我可以创建存储桶并将对象放入其中，列出内容并删除存储桶。我唯一不能做的就是删除后再次创建相同的存储桶。

在下面显示的堆栈跟踪中，我之前创建了一个名为 gormanm-0709-r-o-o-t 的存储桶，使用它，然后通过s3.deleteBucket("gormanm-0709-r-o-o-t") 将其删除。然后我尝试通过s3.createBucket("gormanm-0709-r-o-o-t", "us-standard") 重新创建它，但得到如下所示的错误。

com.amazonaws.services.s3.model.AmazonS3Exception: Container gormanm-0709-r-o-o-t exists (Service: Amazon S3; Status Code: 409; Error Code: BucketAlreadyExists; Request ID: 1be8b569-3db4-4eff-bf1e-c4b8dac20272), S3 Extended Request ID: null
	at com.amazonaws.http.AmazonHttpClient$RequestExecutor.handleErrorResponse(AmazonHttpClient.java:1588)
	at com.amazonaws.http.AmazonHttpClient$RequestExecutor.executeOneRequest(AmazonHttpClient.java:1258)
	at com.amazonaws.http.AmazonHttpClient$RequestExecutor.executeHelper(AmazonHttpClient.java:1030)
	at com.amazonaws.http.AmazonHttpClient$RequestExecutor.doExecute(AmazonHttpClient.java:742)
	at com.amazonaws.http.AmazonHttpClient$RequestExecutor.executeWithTimer(AmazonHttpClient.java:716)
	at com.amazonaws.http.AmazonHttpClient$RequestExecutor.execute(AmazonHttpClient.java:699)
	at com.amazonaws.http.AmazonHttpClient$RequestExecutor.access$500(AmazonHttpClient.java:667)
	at com.amazonaws.http.AmazonHttpClient$RequestExecutionBuilderImpl.execute(AmazonHttpClient.java:649)
	at com.amazonaws.http.AmazonHttpClient.execute(AmazonHttpClient.java:513)
	at com.amazonaws.services.s3.AmazonS3Client.invoke(AmazonS3Client.java:4187)
	at com.amazonaws.services.s3.AmazonS3Client.invoke(AmazonS3Client.java:4134)
	at com.amazonaws.services.s3.AmazonS3Client.createBucket(AmazonS3Client.java:1021)
	at com.amazonaws.services.s3.AmazonS3Client.createBucket(AmazonS3Client.java:973)
	at com.ibm.saas.file.cos.CosFile.createBucket(CosFile.java:794)
	at com.ibm.saas.file.cos.CosFile.ensureBucketExists(CosFile.java:781)
	at com.ibm.saas.file.cos.CosFile.mkdirs(CosFile.java:665)
	at com.ibm.saas.file.cos.CosFileServiceTest.testDir(CosFileServiceTest.java:148)
	at com.ibm.saas.file.cos.CosFileServiceTest.testRootOperations(CosFileServiceTest.java:82)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
	at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
	at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
	at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
	at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
	at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)

我确定我删除了它（因为代码没有引发任何异常，并且我没有看到存储桶出现在 Bluemix/Softlayer 控制台中）并且我确定没有其他人“跳过”我的存储桶名称因为我一遍又一遍地做这个测试。

我的猜测是，在存储桶名称再次可供使用之前还有一段时间，但我只是猜测，即使这是真的，也应该有一些文档在某处解释规则。

说到文档，Getting Help 页面说去这里 (https://developer.ibm.com/answers/smartspace/public-cloud-object-storage/) 提问，但该页面不存在。

【问题讨论】：

而且，奇怪的是，有时错误消息会有些不同。如上所示运行完全相同的单元测试，但这次错误不是“容器 xxx 存在”，而是“请求的存储桶名称不可用”：
com.amazonaws.services.s3.model.AmazonS3Exception：请求的存储桶名称不可用。存储桶命名空间由系统的所有用户共享。请选择其他名称，然后重试。（服务：Amazon S3；状态代码：409；错误代码：BucketAlreadyExists；请求 ID：4fafce9f-8852-4ec4-a1b7-57be9fb7fff7），S3 扩展请求 ID：null
更新：等了一个小时，再次运行完全相同的测试，这一次，它工作了（但现在，删除该存储桶后，我现在必须再等 xxx 分钟才能使用它的名称再次使用）。因此，在可以重用存储桶名称之前，似乎确实存在一些超时时间，但同样，没有任何文档说明它。谁能确认或否认？
这是 IBM Cloud Object Storage 中的存储区，而不是 S3，对吧？无论哪种方式，存储桶删除都可能是后端的低优先级操作，需要跨多个分布式位置进行协调，并且会产生 DNS 后果，因此它不是即时的也就不足为奇了。
关于获取帮助链接，有关云对象存储及其功能的问题页面是developer.ibm.com/answers/smartspace/cloudobjectstorage。该链接目前在文档中是正确的。

标签： amazon-web-services amazon-s3 ibm-cloud object-storage

【解决方案1】：

在 IBM COS 中，存储桶删除后有 10 分钟的时间段保留名称。此延迟可防止命令可能写入已删除存储桶的可能缓存问题。这种可能性很小，我们可能会将这个窗口缩小一点，但一般来说，删除和重新创建存储桶并不是一个好习惯。您是否有特殊原因需要在您的工作流程中执行此操作？

是的，正如@jarmod 在顶级 cmets 中所提到的，这种行为是由于控制对象切片和重组的大量分布式逻辑设备造成的。存储桶删除仍然大部分立即一致，因为在收到 204 响应后将无法进行写入和列出，但可以更好地记录此行为。

虽然 Michael 的回答是指 AWS S3，但对于我们的实施来说，这些信息或多或少是准确的。

【讨论】：

谢谢。所以我的理由是正确的——IBM COS 是一个完全不同的、从头开始的“云存储”实现，只是碰巧使用与 AWS 相同的 S3 API，因此，IBM COS 实现细节和副作用可能是完全不同的与 AWS 不同？或者 IBM COS 后端实施是否建立在 AWS S3 之上（在这种情况下，我应该期望 AWS 文档中讨论的任何行为都适用于 IBM COS）？
顺便说一句 - 回答您关于为什么我可能会删除存储桶并使用相同名称重新创建它们的问题，这仅仅是因为我正在创建一个可以使用的供应商中立客户端 API任何云存储实现，所以我自然拥有前端 createBucket 和 deleteBucket 的 API，因此（a）我无法控制我的开发人员可能会做什么，并且（b）只运行简单的单元测试，我必须“设置”和“拆卸”在每次测试之间，设置和拆卸的一部分包括创建或删除一些存储桶。
因为我的每个单元测试都使用相同的存储桶名称，所以我的第一个测试总是会通过，而所有后续测试总是会失败。
好问题。 IBM COS 建立在 Cleversafe 开发的软件之上，后者于 2015 年底被 IBM 收购。存储引擎本身与 S3 完全不同，但在公共云中，顶部边缘接口层使用与 S3 兼容的 API。这主要是因为 S3 是最接近“标准”对象存储 API 的东西，而且它为许多开发人员所熟悉。所以是的，细节和副作用可能会有所不同，但任何面向应用程序的外观和感觉都应该是相同的，目的是保持与 S3 工具和 SDK 的兼容性。
我完全理解你的情况——就在昨天我们遇到了这个问题的另一端。为了避开冷却期，我们尝试为每个测试创建新的存储桶，然后遇到每个帐户 100 个存储桶的限制。 :(

【解决方案2】：

来自 S3 开发人员指南：

存储桶所有权不可转让；但是，如果存储桶为空，您可以将其删除。删除存储桶后，该名称可重复使用，但由于各种原因，您可能无法重复使用该名称。例如，其他一些账户可以创建一个具有该名称的存储桶。 还要注意，名称可能需要一些时间才能重复使用。所以如果你想使用相同的存储桶名称，请不要删除存储桶。 [强调添加]

http://docs.aws.amazon.com/AmazonS3/latest/dev/BucketRestrictions.html

您有关于预期延迟的文档，还有一个额外的提示：您确实不应该删除和重新创建存储桶。由于存储桶命名空间是全局的，因此在任何给定时间只能存在一个给定名称的存储桶，当然也只能在一个区域中。存储桶仅在您不再需要它们时才被删除 - 否则，清空对象存储桶，但保留存储桶。有人可能会抢购这个名字，如果它特别不晦涩的话。还有：

Amazon S3 的高可用性工程专注于获取、放置、列出和删除操作。由于存储桶操作针对集中的全局资源空间，因此不适合在应用程序的高可用性代码路径上创建或删除存储桶。最好在您不经常运行的单独初始化或设置例程中创建或删除存储桶。

http://docs.aws.amazon.com/AmazonS3/latest/dev/BucketRestrictions.html

虽然细节不公开，但所有 S3 区域在某种意义上都知道所有存储桶。如果您向错误区域发送 S3 请求，则该错误区域确实知道正确的区域，并且将返回包含（显然未记录的）x-amz-bucket-region: response header 的错误。

因此，在创建存储桶时（无论区域如何），在创建存储桶时必然会与 S3 全局数据库进行一些内部通信。这里的中断可能会阻止在任何区域创建存储桶，即使该区域在其他方面运行正常。

请注意，在撰写本文时，文档的另一部分 S3 入门指南提供了基本相同的信息；但是，至少在 2015 年底之前，那里提供的信息有所不同。

当您删除存储桶时，可能会延迟长达一小时，然后存储桶名称才能在新区域或新存储桶所有者中重复使用。如果您在同一区域或使用相同的存储桶所有者重新创建存储桶，则不会延迟。

https://web.archive.org/web/20150905132716/http://docs.aws.amazon.com/AmazonS3/latest/gsg/DeletingAnObjectandBucket.html

直觉上，我怀疑 S3 的持续增长可能使这些信息在它被删除之前就已经过时了，在 2015 年的这个快照之前。

【讨论】：

谢谢。我没有查看 AWS 文档，因为我使用的是 IBM Cloud Object Storage，虽然采用相同的 S3 API，但它是它自己的实现，我遇到的不是 API 问题，而是实现问题，而是你的解释关于 AWS 的工作原理，我猜想 IBM COS 也是如此，由于上述所有原因，存储桶的删除和名称的重用需要一段解冻期。