我最近同时帮助了我们的两个赞助商，星展银行（DBS Bank）和 MariaDB Plc，解决他们最近遇到的一个问题。这实际上也帮助我们增加了对另一个云供应商的支持。但在我讲述这个故事之前，我需要先介绍一些背景信息。
S3 引擎历史
早在2019年，我们将 S3 引擎添加到 MariaDB Server 中。“S3” 代表 “简单存储服务”（Simple Storage Service），它由亚马逊（Amazon）开发，几乎是云中存储对象（通常是文件）的标准。几乎每个云供应商都有自己的对象存储，并提供 S3 兼容的 REST API。
2019年，我在 MariaDB 公司工作，领导 MariaDB ColumnStore 项目。我们需要一个用于 ColumnStore 的 S3 存储后端，与此同时，Monty 正在为 MariaDB Server 开发一个 S3 引擎。我们跨团队合作开展了这些项目并分工协作。亚马逊有一个很棒的 SDK，可以与其云的所有部分一起使用。但它的许可证与 MariaDB Server 不兼容，因此我们无法轻易使用这个 SDK。此外，我们只需要 S3 提供的庞大功能的一个子集，而这个子集本身是 SDK 的一个子集。因此，我们决定创建自己的库来提供我们需要的 API 部分。
我很快创建了这个库，以提供所需的功能，它叫做 libmarias3（我没有太多时间来想一个酷的名字）。我的团队使用这个库开发了 ColumnStore 存储管理器，而 Monty 使用这个库开发了 S3 引擎。
S3 引擎本身基于 Aria 引擎，它是一种只读的归档存储，用于存储您的数据。它可以通过 ALTER TABLE 来实现表在本地/远程存储之间的拉入和推出。如果您在云中需要存储大量报告数据，以这种方式进行存储比将所有数据存储在本地存储上要便宜得多。
随着时间的推移，我们增加了与其他云供应商的兼容性，这些供应商对其 S3 实现的工作方式与亚马逊的有所微调。当然，我已经离职并现在为 MariaDB 基金会工作。
手头的问题
我们的两个赞助商，MariaDB Plc 和星展银行（DBS Bank），要求我们帮助他们解决 S3 引擎与华为 OceanStor 的兼容性问题。我是这项工作的合适人选，因为我对 libmarias3 非常了解，而且增加对华为 OceanStor 的支持将来也能帮助其他 MariaDB Server 用户。
核心问题（工单 MDEV-34867）是 libmarias3 底层的 libcurl 在 REST 请求中默认发送了一个 Content-Type: application/x-www-form-urlencoded 的头部。文件的 mime 类型并不是那么重要，所以我们没有实现正确的 mime 类型处理，并且到目前为止这对所有使用过的供应商都有效。但事实证明，华为 OceanStor 会拒绝使用此头部的请求。
此问题的修复是双重的。首先，libmarias3 现在有一个选项可以在未设置 mime 类型时禁用发送该特定头部。此外，我增加了对文件设置和检索 mime 类型的支持。修复的第二部分是 S3 引擎中的一个新选项，称为 S3-provider。此选项允许为特定云供应商提供一种“兼容模式”（quirks mode）。因此，设置 S3-provider=Huawei 将在未设置 Content-Type: 头部时禁用发送该头部。
结论
基金会独特的地位意味着我们可以轻松地帮助解决影响多个赞助商的问题。这使我们能够支持更多外部存储供应商，并让我们的用户有更多选择。
此修复本身将很快在 10.6 及更高版本的更新中推出。