BigQuery 存储写 / managedwriter api 返回错误 server_shutting_down

Question

正如我们所知， BigQuery Storage Write API 的优势，一个月前，我们将服务器上的insertAll替换为 managedwriter API。 好像用了一个月还不错，但是最近遇到如下错误

rpc error: code = Unavailable desc = closing transport due to: connection error: 
desc = "error reading from server: EOF", received prior goaway: code: NO_ERROR, 
debug data: "server_shutting_down"

managedwriter API 的版本是：

cloud.google.com/go/bigquery v1.25.0
google.golang.org/protobuf v1.27.1

存储写入 API 有一段重试逻辑，用于检测我们服务器端的错误消息。 我们注意到重试后存储写入 API 的响应时间变得更长，因此我们的服务器发生了 OOM。 我们还尝试将请求超时增加到 30 秒，并且其中大部分请求无法在其中完成。

如何正确处理错误server_shutting_down？

更新 02/08/2022

我们服务器使用的是managedwrite API默认的stream。 并且server_shutting_down错误会定期出现。 这个问题发生在 02/04/2022 02/04/2022 12:00 PM UTC ，managedwrite API 的默认 stream 运行了一个多月。

这是 appendRow 的一个包装器appendRow ，我们记录了这个 function 的成本时间。

func (cl *GBOutput) appendRows(ctx context.Context,datas [][]byte, schema *gbSchema) error {
    var result *managedwriter.AppendResult
    var err error
    if cl.schema != schema {
        cl.schema = schema
        result, err = cl.managedStream.AppendRows(ctx, datas, managedwriter.UpdateSchemaDescriptor(schema.descriptorProto))
    } else {
        result, err = cl.managedStream.AppendRows(ctx, datas)
    }
    if err != nil {
        return err
    }
    _, err = result.GetResult(ctx)
    return err
}

当错误server_shutting_down出现时，这个function 的成本时间可能是几百秒。 太奇怪了，似乎没有办法处理appendRow的超时。

Answer 1

您使用的是“原始” v1 存储 API还是managedwriter ？ 我问是因为 managedwriter 应该自动处理 stream 重新连接。 您只是观察连接定期关闭，还是您的重试流量导致关闭？

有趣的问题是如何处理您尚未收到确认返回（或 ack 以失败告终）的正在运行的追加。 如果您使用的是偏移量，您应该能够重新发送 append 而没有重复的风险。

Answer 2

根据 GCP 支持人员的说法，

一旦通过连接发送了 10MB，就会出现此问题，无论需要多长时间或当时有多少正在运行。 BigQuery 工程团队已经确定了根本原因，并将在 2022 年 2 月 11 日星期五之前推出修复程序。