投票：过去一年使用 MariaDB 时，以下哪些稳定性问题对您造成了影响？

我们的第三次投票旨在更好地了解您，通过了解过去一年使用 MariaDB 时，以下哪些稳定性问题对您造成了影响。这有助于我们缩小 MariaDB Server 稳定性的主要问题范围，并帮助我们据此优先解决它们。

受访者可以对每个选项投票，分配 1 到 4 颗星

  • 1 颗星 – 未受影响
  • 2 颗星 – 影响较低
  • 3 颗星 – 影响较高
  • 4 颗星 – 影响严重
=

加入对话

8 条评论

  1. 您好，
    目前我使用 MariaDB 没有问题，只有一个问题是 Windows 7 早期版本中在照片存储中使用 blob 字段。
    谢谢

    回复

  2. 自将 MariaDB 从 5.5 升级到 10.5（期间经历了每个主要版本）以来，出现了严重的内存泄漏问题。现在 mariadb 进程会在几个月内泄漏数十 GB 的内存，一旦快要泄漏系统中所有可用内存时，就需要重启。5.5 版本非常稳定，可以使用多年而无需重启。真心希望这个问题能在即将到来的更新中得到解决。

    回复
    1. 回复

  3. 过去一年中，自从采用 10.5.x 版本以来，我遇到的最大麻烦是：

    1) 异步并行行复制在非常高的 I/O 速率下出现周期性复制失败，导致集群中断 ~ 10.5.8（可能已经解决，我们目前已将其禁用）
    2) 查询优化器 Bug 导致 MariaDB 选择错误的索引，从而导致查询时间非常长 ~ 10.5.8 – 10.5.12（工单已开，已有临时解决方案，不确定是否已修复）
    3) `Optimize Table` 的原地算法似乎有效，但导致系统严重损坏 ~ 10.5.12（昨天刚发现。导致查询变慢且表空间不断增长而不是重复利用表空间，之前表空间为 85GB，优化后应剩余约 15GB，一天后表空间变为 145GB，尚未提交工单）
    4) `Table Definition Cache` 值为 -1 导致数据库 OOM 崩溃。系统创建了大量临时表并使用了持久连接，可能与此有关 ~ 10.5.8 – 10.5.12（工单已开，是的，我还没来得及跟进）

    回复

  4. * 未记录的或未提供正当理由的非最小意外更改，有时会破坏复制
    * 内存泄漏迫使每隔几周重启服务器
    * GTID 模型在动态环境和备份恢复中不起作用
    * 由于索引数据损坏导致频繁崩溃
    * mysql_upgrade 更新授权的方式不符合预期

    回复
  5. 回复
  6. 回复
  7. 回复

发表评论

您的电子邮件地址不会被发布。 必填字段用 * 标记