4

在过去的几周里，我们使用数据存储管理工具对数据存储进行完整备份一再失败。我们认为问题与我们遇到的配额错误有关，因此我们将应用程序从免费应用程序切换到付费应用程序，但我们仍然遇到问题。

每次我们尝试备份到 blobstore 时，都会发生该过程永远不会完成的情况。我们在 Pending Backups 列表中看到了备份，但它从未真正完成。我们现在总共只有 43MB 的数据，所以我们不认为这是一个数据传输问题。查看我们的默认任务队列，它显示我们有两个待处理任务，一个是对 /_ah/mapreduce/controller_callback 的调用，另一个是对 /_ah/mapreduce/worker_callback 的调用

worker_callback 累积了它的重试计数，我们唯一的错误线索是在 Previous Run 选项卡上，它显示最后一个 http 响应代码为 500。没有错误消息，我们的错误日志中没有任何内容，它只是不断尝试一遍又一遍。

我们已经能够将备份问题缩小到特定命名空间的特定实体类型，但我们无法弄清楚为什么该实体类型失败而其他实体类型失败。主要区别在于实体类型具有大量嵌入式实体，但如果应用引擎能够读取/放置这些实体，我们无法理解为什么它似乎在备份它时出现问题。与我们设置的其他命名空间相比，发生错误的特定命名空间具有为该实体类型存储的最大数据。

我们认为，如果我们可以看到 worker_callback 中发生了什么错误，我们可能能够找出备份失败的原因，或者我们的数据有什么问题阻止了备份。我们是否需要通过设置/配置文件来设置/启用，以便为我们提供有关备份的更详细信息？还是我们应该探索其他途径来弄清楚如何调查/解决这个问题？

我应该提到我们正在使用 Java SDK 以及 Objectify V3 来处理数据存储。我们还将数据备份到 Blobstore。

谢谢你。

4

2 回答 2

3

好吧，在应用引擎团队的帮助下，我们找出了问题所在，并解决了这个问题。我想提供详细信息，以防其他人遇到此问题。

从issue 8363开始，应用引擎团队指出，从他们的日志中他们可以看到 map reduce 失败，因为我们的实体类型具有大量属性。导致失败的特定实体类型具有大量变量属性，当 map reduce 尝试写出模式时会生成错误。他们表示，他们的解决方案是忽略备份中这样的实体，以便备份成功。

我们为解决这个问题和使备份工作所做的工作是改变我们告诉 objectify 存储数据的方式。由于我们在 HashMap() 类成员字段上使用了 @embedded 关键字，因此创建了大量属性。由于 Embedded 关键字将类分解为单独的组件，因此它会生成大量属性。我们将成员字段切换为@serialized，然后运行转换过程以使其使用新的序列化属性。这使备份/恢复再次工作。

您可以在objectify 的网站上阅读有关嵌入式和序列化之间差异的更多信息

于 2012-10-31T17:13:33.597 回答
0

snielson，你介意在我们的公共问题跟踪器上打开一个问题吗？请记住添加您的应用程序 ID，以便我们可以进一步调试此特定场景。

谢谢！

于 2012-10-25T20:42:40.260 回答