(转)解决mysqldump: Got error: 1290以及secure-file-priv option简解

本文介绍了解决MySQL备份过程中出现的1290错误的方法,通过调整secure_file_priv参数来允许mysqldump命令正常执行。并提供了如何在配置文件中设置此参数的具体步骤。

转自http://blog.itpub.net/31386161/viewspace-2130313/

今天有个网友问,在用mysqldump备份时候遇到1290的错误
下面是是我模拟他的报错信息
[root@potato Desktop]# mysqldump -uroot -proot -S /tmp/mysql.sock --tab=/data/mysql/mytest_3306/data/backup lala
Warning: Using a password on the command line interface can be insecure.
mysqldump: Got error: 1290: The MySQL server is running with the --secure-file-priv option so it cannot execute this statement when executing 'SELECT INTO OUTFILE'

可以很清楚地从提示看到是因为mysql服务启用了–secure-file-priv,所以才无法执行。
那么–secure-file-priv又是什么东东,应该如何解决才能是它可以备份呢?
--secure-file-priv=name :
Limit LOAD DATA, SELECT ... OUTFILE, and LOAD_FILE() to files within specified directory

可以看到secure-file-priv参数是用来限制LOAD DATA, SELECT … OUTFILE, and LOAD_FILE()传到哪个指定目录的。

当secure_file_priv的值为null ,表示限制mysqld 不允许导入|导出

当secure_file_priv的值为/tmp/ ,表示限制mysqld 的导入|导出只能发生在/tmp/目录下

当secure_file_priv的值没有具体值时,表示不对mysqld 的导入|导出做限制

查看数据库当前该参数的值
root@localhost:mysql.sock 00:14:52 [(none)]>show global variables like '%secure%';
+------------------+-------+
| Variable_name | Value |
+------------------+-------+
| secure_auth | ON |
| secure_file_priv | NULL |
+------------------+-------+
2 rows in set (0.00 sec)

清楚地看到secure_file_priv 的值是NULL,说明此时限制导入导出的
所以应该改变该参数
可是查看了mysql.cnf中居然没有对这个参数进行设定,就说明这个参数默认便是null
所以再mysql.cnf中的[mysqld]加入secure_file_priv =
再重启mysql服务
然后再查一下此时参数的值

root@localhost:mysql.sock 00:28:30 [(none)]>show global variables like '%secure%';
+------------------+-------+
| Variable_name | Value |
+------------------+-------+
| secure_auth | ON |
| secure_file_priv | |
+------------------+-------+
2 rows in set (0.00 sec)

已经是我们要的结果
开始进行导出
[root@potato Desktop]# mysqldump -uroot -proot -S /tmp/mysql.sock --tab=/data/mysql/mytest_3306/data/backup lala
Warning: Using a password on the command line interface can be insecure.

可以看到成功了


ps:

偷懒用了phpstudy 一键安装,一开始去C:/里面找的mysql里面的my.ini就是错误的。这个路径C:\phpStudy\MySQL才是对的。

打开后发现没有secure_file_priv这个选项,直接添加一个空的即可。

2025-10-28T19:45:58.820318+08:00 0 [Note] - '::' resolves to '::'; 2025-10-28T19:45:58.821280+08:00 0 [Note] Server socket created on IP: '::'. 2025-10-28T19:45:58.846650+08:00 0 [Note] InnoDB: Buffer pool(s) load completed at 251028 19:45:58 2025-10-28T19:45:58.911119+08:00 0 [Note] Event Scheduler: Loaded 0 events 2025-10-28T19:45:58.912084+08:00 0 [Note] D:\newmysql\mysql-5.7.12-winx64\bin\mysqld: ready for connections. Version: '5.7.12-log' socket: '' port: 3306 MySQL Community Server (GPL) 2025-10-28T20:39:45.659482+08:00 15 [ERROR] InnoDB: Operating system error number 32 in a file operation. 2025-10-28T20:39:45.660451+08:00 15 [ERROR] InnoDB: The error means that another program is using InnoDB's files. This might be a backup or antivirus software or another instance of MySQL. Please close it to get rid of this error. 2025-10-28 20:39:55 0x740c InnoDB: Assertion failure in thread 29708 in file handler0alter.cc line 7404 InnoDB: Failing assertion: error == DB_SUCCESS InnoDB: We intentionally generate a memory trap. InnoDB: Submit a detailed bug report to http://bugs.mysql.com. InnoDB: If you get repeated assertion failures or crashes, even InnoDB: immediately after the mysqld startup, there may be InnoDB: corruption in the InnoDB tablespace. Please refer to InnoDB: http://dev.mysql.com/doc/refman/5.7/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 2025-10-28T20:39:55.663376+08:00 0 [Note] InnoDB: page_cleaner: 1000ms intended loop took 9553ms. The settings might not be optimal. (flushed=0 and evicted=0, during the time.) 12:39:55 UTC - mysqld got exception 0x80000003 ; This could be because you hit a bug. It is also possible that this binary or one of the libraries it was linked against is corrupt, improperly built, or misconfigured. This error can also be caused by malfunctioning hardware. Attempting to collect some information that could help diagnose the problem. As this is a crash and something is definitely wrong, the information collection process might fail. key_buffer_size=536870912 read_buffer_size=131072 max_used_connections=51 max_threads=600 thread_count=50 connection_count=50 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 761977 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x26ebec94ce0 Attempting backtrace. You can use the following information to find out where mysqld died. If you see no messages after this, something went terribly wrong... 7ff754c49812 mysqld.exe!my_sigabrt_handler()[my_thr_init.c:449] 7ff754fee349 mysqld.exe!raise()[winsig.c:587] 7ff754fed240 mysqld.exe!abort()[abort.c:82] 7ff754d49b08 mysqld.exe!ut_dbg_assertion_failed()[ut0dbg.cc:67] 7ff754e2f72f mysqld.exe!ha_innobase::commit_inplace_alter_table()[handler0alter.cc:8275] 7ff7545c1443 mysqld.exe!mysql_inplace_alter_table()[sql_table.cc:7449] 7ff7545bf17a mysqld.exe!mysql_alter_table()[sql_table.cc:9538] 7ff7546e565e mysqld.exe!Sql_cmd_alter_table::execute()[sql_alter.cc:316] 7ff754546aa5 mysqld.exe!mysql_execute_command()[sql_parse.cc:3521] 7ff75454938a mysqld.exe!mysql_parse()[sql_parse.cc:5525] 7ff75454239d mysqld.exe!dispatch_command()[sql_parse.cc:1432] 7ff7545433aa mysqld.exe!do_command()[sql_parse.cc:999] 7ff7545081e4 mysqld.exe!handle_connection()[connection_handler_per_thread.cc:301] 7ff754f2cd92 mysqld.exe!pfs_spawn_thread()[pfs.cc:2191] 7ff754c4967b mysqld.exe!win_thread_start()[my_thread.c:38] 7ff754feddbf mysqld.exe!_callthreadstartex()[threadex.c:376] 7ff754fee00a mysqld.exe!_threadstartex()[threadex.c:354] 7ffaba1f84d4 KERNEL32.DLL!BaseThreadInitThunk() 7ffabc6ee871 ntdll.dll!RtlUserThreadStart() Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (26ebece8580): ALTER TABLE formmain_0495 DROP COLUMN field0028 Connection ID (thread ID): 15 Status: NOT_KILLED The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains information that should help you find out what is causing the crash. 2025-10-28T20:43:23.759825+08:00 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details). 2025-10-28T20:43:23.759825+08:00 0 [Warning] Insecure configuration for --secure-file-priv: Current value does not restrict location of generated files. Consider setting it to a valid, non-empty path. 2025-10-28T20:43:23.760771+08:00 0 [Note] D:\newmysql\mysql-5.7.12-winx64\bin\mysqld (mysqld 5.7.12-log) starting as process 39684 ... 2025-10-28T20:43:23.818393+08:00 0 [Note] InnoDB: Mutexes and rw_locks use Windows interlocked functions 2025-10-28T20:43:23.819370+08:00 0 [Note] InnoDB: Uses event mutexes 2025-10-28T20:43:23.819370+08:00 0 [Note] InnoDB: _mm_lfence() and _mm_sfence() are used for memory barrier 2025-10-28T20:43:23.820343+08:00 0 [Note] InnoDB: Compressed tables use zlib 1.2.3 2025-10-28T20:43:23.821322+08:00 0 [Note] InnoDB: Number of pools: 1 2025-10-28T20:43:23.822294+08:00 0 [Note] InnoDB: Not using CPU crc32 instructions 2025-10-28T20:43:23.866243+08:00 0 [Note] InnoDB: Initializing buffer pool, total size = 8G, instances = 8, chunk size = 128M 2025-10-28T20:43:24.265683+08:00 0 [Note] InnoDB: Completed initialization of buffer pool 2025-10-28T20:43:24.414092+08:00 0 [Note] InnoDB: Highest supported file format is Barracuda. 2025-10-28T20:43:24.508818+08:00 0 [Note] InnoDB: Log scan progressed past the checkpoint lsn 933908534 2025-10-28T20:43:24.633818+08:00 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 933994745 2025-10-28T20:43:24.639683+08:00 0 [Note] InnoDB: Ignoring data file '.\oa\formmain_0495.ibd' with space ID 1585. Another data file called .\oa\#sql-ib1600-4242521553.ibd exists with the same space ID. 2025-10-28T20:43:24.641629+08:00 0 [Note] InnoDB: Ignoring data file '.\oa\formmain_0495.ibd' with space ID 1583. Another data file called .\oa\#sql-ib1602-4242521554.ibd exists with the same space ID. 2025-10-28T20:43:24.643587+08:00 0 [Note] InnoDB: Ignoring data file '.\oa\formmain_0495.ibd' with space ID 1585. Another data file called .\oa\#sql-ib1600-4242521553.ibd exists with the same space ID. 2025-10-28T20:43:24.647490+08:00 0 [Note] InnoDB: Ignoring data file '.\oa\formmain_0495.ibd' with space ID 1583. Another data file called .\oa\#sql-ib1602-4242521554.ibd exists with the same space ID. 2025-10-28T20:43:24.661159+08:00 0 [Note] InnoDB: Database was not shutdown normally! 2025-10-28T20:43:24.661159+08:00 0 [Note] InnoDB: Starting crash recovery. 2025-10-28T20:43:24.844755+08:00 0 [Note] InnoDB: 1 transaction(s) which must be rolled back or cleaned up in total 47 row operations to undo 2025-10-28T20:43:24.845734+08:00 0 [Note] InnoDB: Trx id counter is 14848 2025-10-28T20:43:24.859405+08:00 0 [Note] InnoDB: Starting an apply batch of log records to the database... InnoDB: Progress in percent: 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 2025-10-28T20:43:25.704135+08:00 0 [Note] InnoDB: Apply batch completed 2025-10-28T20:43:32.680689+08:00 0 [Note] InnoDB: Starting in background the rollback of uncommitted transactions 2025-10-28T20:43:32.681665+08:00 0 [Note] InnoDB: Removed temporary tablespace data file: "ibtmp1" 2025-10-28T20:43:32.681665+08:00 0 [Note] InnoDB: Rolling back trx with id 14454, 47 rows to undo 2025-10-28T20:43:32.682647+08:00 0 [Note] InnoDB: Creating shared tablespace for temporary tables 2025-10-28T20:43:32.684595+08:00 0 [Note] InnoDB: Setting file '.\ibtmp1' size to 12 MB. Physically writing the file full; Please wait ... 2025-10-28T20:43:32.695334+08:00 0 [Note] InnoDB: Rollback of trx with id 14454 completed 2025-10-28T20:43:32.696312+08:00 0 [Note] InnoDB: Rollback of non-prepared transactions completed 2025-10-28T20:43:32.732452+08:00 0 [Note] InnoDB: File '.\ibtmp1' size is now 12 MB. 2025-10-28T20:43:32.757857+08:00 0 [Note] InnoDB: 96 redo rollback segment(s) found. 96 redo rollback segment(s) are active. 2025-10-28T20:43:32.758821+08:00 0 [Note] InnoDB: 32 non-redo rollback segment(s) are active. 2025-10-28T20:43:32.760764+08:00 0 [Note] InnoDB: Waiting for purge to start 2025-10-28T20:43:32.812522+08:00 0 [Note] InnoDB: 5.7.12 started; log sequence number 933994745 2025-10-28T20:43:32.812522+08:00 0 [Note] InnoDB: page_cleaner: 1000ms intended loop took 8438ms. The settings might not be optimal. (flushed=0 and evicted=0, during the time.) 2025-10-28T20:43:32.813529+08:00 0 [Note] Plugin 'FEDERATED' is disabled. 2025-10-28T20:43:32.813529+08:00 0 [Note] InnoDB: Loading buffer pool(s) from D:\newmysql\mysql-5.7.12-winx64\data\ib_buffer_pool 2025-10-28T20:43:32.830109+08:00 0 [Warning] Failed to set up SSL because of the following SSL library error: SSL context is not usable without certificate and private key 2025-10-28T20:43:32.832067+08:00 0 [Note] Server hostname (bind-address): '*'; port: 3306 2025-10-28T20:43:32.834022+08:00 0 [Note] IPv6 is available. 2025-10-28T20:43:32.834022+08:00 0 [Note] - '::' resolves to '::'; 2025-10-28T20:43:32.835011+08:00 0 [Note] Server socket created on IP: '::'. 2025-10-28T20:43:32.854535+08:00 0 [Note] InnoDB: Buffer pool(s) load completed at 251028 20:43:32 2025-10-28T20:43:32.904319+08:00 0 [Note] Event Scheduler: Loaded 0 events 2025-10-28T20:43:32.905296+08:00 0 [Note] D:\newmysql\mysql-5.7.12-winx64\bin\mysqld: ready for connections. Version: '5.7.12-log' socket: '' port: 3306 MySQL Community Server (GPL) 数据库异常崩溃,这个怎么解决
最新发布
10-29
<think>嗯,用户遇到了在Linux系统中使用MySQL时出现的错误1290,具体是关于--secure-file-priv选项的问题。我需要先理解这个错误的根本原因。 首先,记得MySQL--secure-file-priv选项是用来限制LOAD DATA INFILE和SELECT ... INTO OUTFILE这些语句的文件读写路径的。如果用户尝试导出或导入文件到一个未被允许的目录,就会触发这个错误。那用户可能是在执行类似SELECT INTO OUTFILE或者LOAD DATA INFILE的命令时遇到了问题。 接下来,我需要考虑如何查看当前MySQLsecure_file_priv设置。通常可以通过登录MySQL后执行SHOW VARIABLES LIKE 'secure_file_priv';来获取这个值。如果这个值被设置为某个特定目录,用户必须在该目录下操作。如果值为NULL,说明禁止所有文件操作,这时候可能需要修改配置文件。 用户可能需要修改MySQL的配置文件,比如my.cnf或my.ini,在[mysqld]部分添加或修改secure-file-priv的路径。修改后需要重启MySQL服务,比如用systemctl restart mysql。之后再次检查该变量是否生效。 另外,如果用户无法修改全局配置,临时解决方案可以是使用已经允许的目录,比如默认的/var/lib/mysql-files/。或者,如果有权限的话,将文件移动到该目录下进行操作。 还要考虑到权限问题,确保MySQL用户有对目标目录的读写权限。可能需要使用chown或chmod调整权限。 安全方面,修改secure-file-priv可能会降低系统安全性,所以需要提醒用户谨慎处理,尤其是在生产环境中。建议仅在必要时调整,并确保目录权限正确。 用户可能还关心如何彻底解决这个问题,或者是否有其他替代方法。比如是否可以使用其他数据导入导出方式,如mysqldump工具,来避免文件权限问题。这可能是一个补充建议,帮助用户找到替代方案。 最后,生成相关问题时要覆盖常见的情况,比如检查设置、修改配置、替代方法以及安全性考虑,这样用户能全面了解问题及其解决方案。</think>### Linux MySQL错误1290解决方案 当使用$SELECT...INTO\ OUTFILE$或$LOAD\ DATA\ INFILE$语句时,MySQL的$secure_file_priv$系统变量会限制文件读写路径。出现错误代码1290时,可通过以下步骤排查: #### 一、检查当前配置 ```sql SHOW VARIABLES LIKE 'secure_file_priv'; ``` 该命令将显示允许文件操作的目录路径,可能返回三种结果: 1. `/var/lib/mysql-files/`(默认值)[^1] 2. `NULL`(完全禁用文件操作) 3. 自定义路径(如`/tmp/`) #### 二、临时解决方案 1. **使用允许的目录**(以默认路径为例): ```sql SELECT * INTO OUTFILE '/var/lib/mysql-files/output.csv' FROM table; ``` 2. **移动现有文件**: ```bash sudo mv /home/user/data.csv /var/lib/mysql-files/ ``` #### 三、永久解决方案 1. 编辑MySQL配置文件: ```bash sudo vim /etc/mysql/my.cnf ``` 2. 在`[mysqld]`段添加: ``` secure_file_priv = /your/custom/path/ ``` 3. 重启服务: ```bash sudo systemctl restart mysql ``` #### 四、权限验证 确保MySQL用户具有目标目录的读写权限: ```bash sudo chown -R mysql:mysql /your/custom/path sudo chmod 755 /your/custom/path ``` > **安全提示**:放宽$secure_file_priv$限制会增加安全风险,建议生产环境保持默认配置[^2]
评论 2
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值