MariaDB - 无法通过 my.cnf 设置 max_connections 和 wait_timeout

Question

我正在努力在 /etc/my.cnf 中设置 max_connections 和 wait_timeout 参数，但 MariaDB 似乎没有从文件中读取参数（它读取了其他一些参数，我还没有全部检查）。

我的 /etc/my.cnf 文件：

[mysqld]
#skip-grant-tables
datadir=/data/mysql
socket=/data/mysql/mysql.sock
# Disabling symbolic-links is recommended to prevent assorted security risks
symbolic-links=0

# network
connect_timeout = 61
wait_timeout = 86400
max_connections = 100000
max_allowed_packet = 64M
max_connect_errors = 1000

# limits
tmp_table_size = 512M
max_heap_table_size = 256M
table_cache = 512

[mysqld_safe]
log-error=/var/log/mariadb/mariadb.log
pid-file=/var/run/mariadb/mariadb.pid

[client]
port = 3306
socket= /data/mysql/mysql.sock

但是当我检查 MariaDB 中的 max_connections 和 wait_timeout 变量时，它显示了默认值：

MariaDB [(none)]> show variables like 'max_connections';
+-----------------+-------+
| Variable_name   | Value |
+-----------------+-------+
| max_connections | 214   |
+-----------------+-------+
1 row in set (0.00 sec)

MariaDB [(none)]> show variables like 'wait_timeout';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| wait_timeout  | 28800 |
+---------------+-------+
1 row in set (0.00 sec)

但是，my.cnf 中的其他参数是正确的：

MariaDB [(none)]> show variables like 'max_allowed_packet';
+--------------------+----------+
| Variable_name      | Value    |
+--------------------+----------+
| max_allowed_packet | 67108864 |
+--------------------+----------+
1 row in set (0.00 sec)


MariaDB [(none)]> show variables like 'max_connect_errors';
+--------------------+-------+
| Variable_name      | Value |
+--------------------+-------+
| max_connect_errors | 1000  |
+--------------------+-------+
1 row in set (0.00 sec)

MariaDB [(none)]> show variables like 'connect_timeout';
+-----------------+-------+
| Variable_name   | Value |
+-----------------+-------+
| connect_timeout | 61    |
+-----------------+-------+
1 row in set (0.00 sec)

我可以从 mysql 命令行设置 max_connections 变量，但是当我重新启动服务时它会自行重置：

MariaDB [(none)]> set global max_connections := 10000;
Query OK, 0 rows affected (0.00 sec)

MariaDB [(none)]> show variables like 'max_connections';
+-----------------+-------+
| Variable_name   | Value |
+-----------------+-------+
| max_connections | 10000 |
+-----------------+-------+
1 row in set (0.00 sec)

但是，对于 wait_timeout 这不起作用：

MariaDB [(none)]> set global wait_timeout = 86400;                                                                            Query OK, 0 rows affected (0.00 sec)

MariaDB [(none)]> show variables like 'wait_timeout';                                                                         +---------------+-------+
| Variable_name | Value |
+---------------+-------+
| wait_timeout  | 28800 |
+---------------+-------+
1 row in set (0.00 sec)

等待超时设置为会话变量：

MariaDB [(none)]> SELECT * FROM information_schema.global_variables WHERE variable_name='wait_timeout' UNION SELECT * FROM information_schema.session_variables WHERE variable_name='wait_timeout';
+---------------+----------------+
| VARIABLE_NAME | VARIABLE_VALUE |
+---------------+----------------+
| WAIT_TIMEOUT  | 86400          |
| WAIT_TIMEOUT  | 28800          |
+---------------+----------------+
2 rows in set (0.00 sec)

检查所有 my.cnf 文件，没有一个覆盖参数：

[/] # locate my.cnf
/etc/my.cnf
/etc/my.cnf.d
/etc/my.cnf~
/etc/my.cnf.d/client.cnf
/etc/my.cnf.d/mysql-clients.cnf
/etc/my.cnf.d/server.cnf
/root/.my.cnf

操作系统：RHEL 7

MariaDB 版本：mariadb-server-5.5.47-1.el7_2.x86_64

Answer 1

wait_timeout 是一个古怪的人：

“在线程启动时，会话wait_timeout 值从全局wait_timeout 值或全局interactive_timeout 值初始化，具体取决于客户端的类型（由mysql_real_connect() 的CLIENT_INTERACTIVE 连接选项定义）。另见interactive_timeout。“

max_connections声称有 100000 的上限，但我会说即使是 10000 也是不合理的大。它的工作原理把max_connections=1000在my.cnf？

你明白你需要在更改my.cnf后，

1. 重启mysqld
2. 断开连接并重新连接以查看更改
3. 使用SHOW GLOBAL，不SHOW，默认为SHOW SESSION.

GLOBAL和SESSION（对于VARIABLES和STATUS）之间的交互因设置而异。对于许多（并非所有）事情，会话在您登录时被初始化为全局。并且wait_timeout可能是最古怪的。

警告

如果您有 100000 个连接，每个连接都运行复杂，SELECTs需要 3 个 tmp 表，那么您可能需要 100000 * 3 * 256M = 76.8TB 的RAM来处理 tmp 表！( 256M = min(tmp_table_size, max_heap_table_size) )。这是一个强有力的理由，不要把所有这些东西都设置得这么高。