我已经针对 MySQL 打开了一个错误报告 http://bugs.mysql.com/bug.php?id=70793&thanks=4 . 这里有一个代码示例可以证明这个错误。我发现错误报告中还包含一个解决方法。此解决方法适用于 PHP 和控制台
我在存储过程和 PHP PDO 方面遇到了一个奇怪的问题。
我不允许发布存储过程的主体,但我可以提供以下信息。
-
当 从控制台 与 PHP PDO 共享的相同用户访问时,
- 它在只读副本上正常工作 -- 编辑:我在这里的初始报告是部分不正确,如果临时表存在,存储过程将工作;如果临时表在控制台和 pdo 环境中都不存在,则存储过程将失败。有关详细信息,请参阅链接到 MySQL 的错误报告。
- 我已确认我在两个地方使用的是同一个用户。
- 它执行的唯一写入事件是在临时表中
- 它确实使用了游标
- master 和 replica 都运行 MySQL 5.5.27
- MySQL 服务器在 AWS RDS 上进行管理;我有一个标准配置的参数组。
我的问题是我无法从 PHP PDO 调用此存储过程,出现此错误
SQLSTATE[HY000]: General error: 1290 The MySQL server is running with the --read-only option so it cannot execute this statement
这完全没有意义,因为我可以在只读副本上调用它,只要我不是从 PHP 调用它即可。
任何人都可以阐明这里可能发生的事情吗?
编辑更多离奇信息
我可以让控制台 session 失败,但我也可以让它成功。这取决于存储过程使用的临时表是否已经创建。那么让我解释一下我的工作和失败用例
失败
- 在控制台登录服务器
- 尝试调用存储过程
- 失败
MySQL 服务器正在使用 --read-only 选项运行,因此无法执行此语句
通过
- 在控制台登录服务器
- 创建临时表
- 尝试调用存储过程
- 成功
更奇怪的是,我绝对会将该临时表放在存储过程中,如果它存在则重新创建它。
我相当确定此时我们正在查看 MySQL 错误
最佳答案
您是否尝试将 TEMPORARY 关键字添加到 DROP TABLE command ?
TEMPORARY 关键字具有以下作用:
- 该语句只删除临时表。
- 声明不会结束正在进行的交易。
- 没有检查访问权限。 (临时的 表仅对创建它的 session 可见,因此不检查 必要的。)
关于php - 带有 PHP PDO 的只读副本上的 MySQL 存储过程,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/19693661/