mysql - 为什么 mysqldump 进入文件在 docker 容器中不起作用(带有不直观的错误消息)?
问题描述
使用docker 映像时,我会尝试转储数据库的备份,从而mysql:5.7
进入 docker 容器。exec -it /bin/sh
我在 上安装了一个卷/share
,这是我试图保存转储文件的地方。
如果我执行以下操作:
mysqldump -u user -ppassword database
然后我成功地看到屏幕上正在打印数据库的转储。
如果我执行以下操作:
echo "hello world" > /share/dump.sql
然后我成功地看到了/share/dump.sql
包含hello world
.
但是,如果我尝试将其组合成:
mysqldump -u user -ppassword database > /share/dump.sql
然后我得到一个看似无关的错误,说:
错误:'访问被拒绝;尝试转储表空间时,您需要(至少一个)此操作的 PROCESS 特权
显然,这不是缺少特权的情况,因为我的mysqldump
调用没有保存到文件中有效。那么,什么给了?
对于任何想尝试的人,这里是相关的撰写文件:
version: '3.8'
services:
db:
image: mysql:5.7
environment:
MYSQL_DATABASE: database
MYSQL_USER: user
MYSQL_PASSWORD: password
MYSQL_ROOT_PASSWORD: root
volumes:
- ./share:/share
volumes:
db:
解决方案
根据有关权限的mysqldump 参考手册,如果不使用 --no-tablespaces 选项,则需要“和(从 MySQL 5.7.31 开始)PROCESS”。
使用--no-tablespaces
with 进行测试:
$ podman run --rm --name mysql57 -e MYSQL_DATABASE=database \
-e MYSQL_USER=user -e MYSQL_PASSWORD=password \
-e MYSQL_ROOT_PASSWORD=root -d mysql:5.7
8411383e46549f4fd028ee27d74b4799f56e4b23b63321e2e445ebd7577bf411
和执行:
root@8411383e4654:/# mysqldump -u user -ppassword --no-tablespaces database
mysqldump: [Warning] Using a password on the command line interface can be insecure.
-- MySQL dump 10.13 Distrib 5.7.35, for Linux (x86_64)
--
-- Host: localhost Database: database
-- ------------------------------------------------------
-- Server version 5.7.35
/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
/*!40101 SET NAMES utf8 */;
/*!40103 SET @OLD_TIME_ZONE=@@TIME_ZONE */;
/*!40103 SET TIME_ZONE='+00:00' */;
/*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */;
/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;
/*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;
/*!40111 SET @OLD_SQL_NOTES=@@SQL_NOTES, SQL_NOTES=0 */;
/*!40103 SET TIME_ZONE=@OLD_TIME_ZONE */;
/*!40101 SET SQL_MODE=@OLD_SQL_MODE */;
/*!40014 SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS */;
/*!40014 SET UNIQUE_CHECKS=@OLD_UNIQUE_CHECKS */;
/*!40101 SET CHARACTER_SET_CLIENT=@OLD_CHARACTER_SET_CLIENT */;
/*!40101 SET CHARACTER_SET_RESULTS=@OLD_CHARACTER_SET_RESULTS */;
/*!40101 SET COLLATION_CONNECTION=@OLD_COLLATION_CONNECTION */;
/*!40111 SET SQL_NOTES=@OLD_SQL_NOTES */;
-- Dump completed on 2021-10-03 3:20:12
没错,没有错误。
推荐阅读
- flutter - 如何在颤动中剪辑定位小部件的角
- mysql - 用于排除 2 分钟内会话的 SQL 查询
- c++ - 如何找到 map.at 坠毁的位置?
- java - 如何修复 ODI12c 列表软件上的 java.lang.noclassdeffounderror javax/xml/bind/jaxbexception - Oracle DB19c - ODI 12c - JDK 11.0.11
- kubernetes - 使用主机的入口规则
- azure-ad-b2c - AD B2C Rest API 调用中的 ConnectionTimeOut 以获取访问令牌
- python - 内存高效的最近邻算法
- python-3.x - PyTorch .cpu() 与 .to('cpu')
- azure - 如何让远程工作的开发人员访问 Azure SQL Server?
- python - 将不同时间戳格式的多个数据帧堆叠在一起,形成一个时间戳