0

这可能是显而易见的，但我一生都无法弄清楚。自从我们重新启动服务器后，一个使用 mysql++ 连接到我们的数据库的 C++ 程序立即为所有查询返回了 0 行。我的第一个想法是 my.cnf 可能没有正确加载，但在检查显示变量和比较之后似乎是正确的。

有什么建议么？是否有可能某些目录设置无法找到我不知道的 mysqlpp 所需的一些 .so 文件？

任何建议表示赞赏。

4

1 回答 1

0

有什么建议么？

当然：

  1. 如果您已禁用异常，请确保检查所有错误代码返回。

    如果您没有禁用异常，请检查catch可能涉及的每个块不只是悄悄地吃掉错误。

    MySQL C API 库（以及 MySQL++）可能试图告诉您出了什么问题，而您正在压制它或以某种方式忽略它。

  2. 构建并运行示例。如果它们以与您的程序相同的方式失败，则意味着问题本质上是广泛的。这些示例具有良好的诊断功能，因此它们可以指导您解决问题。

    如果示例工作正常，那么问题是特定于您的程序或其数据的。因此，将案例分开：

    • 该程序是否针对与问题机器具有相同结构但内容不同的数据库在不同的机器上运行？

    • 如果是这样，当您将问题数据库的副本加载到第二台机器上时，它是否仍然可以在该机器上工作？

    • 如果这仍然有效，那么当您直接从有效的系统访问远程机器的数据库时它是否有效？（小心这个。你想在 MySQL 数据库连接本身上设置 SSL，或者有某种安全通道，比如 VPN 或 SSH 隧道。）

    如果您成功运行了该挑战，则意味着问题出在原始机器上的程序本身或程序的环境中。正如您所推测的，库或权限是一种可能性。

  3. 在调试器下运行您的程序。

    首先尝试gdb，因为我们感兴趣的是调试器是否看到任何异常或抛出的信号。例如，该程序可能是核心转储。

    如果gdb给程序一个干净的健康证明，请尝试valgrind. 如果 Valgrind 抱怨你的程序，很有可能它抱怨的东西是合法的。也许无害，但​​合法。如果您收到投诉，并且您在上面发现问题是特定于一台机器的，我建议您在程序成功运行的系统上重新尝试运行 Valgrind。修复这些问题，或者至少在原始问题机器上继续调试之前排除无害的警告。

是否有可能某些目录设置无法找到我不知道的 mysqlpp 所需的一些 .so 文件？

很容易检查：

$ ldd myprogram

您应该获得一份报告，其中列出了您的程序链接到的所有共享库，包括它们的完整路径。ldd将指示运行的用户丢失或不可读的任何内容。

于 2012-08-20T21:40:12.667 回答