阻止 MariaDB 锁定进程

Question

我们使用安装了 Magento 的 MariaDB 10.2.14 运行 CentOS DirectAdmin 安装。

目前，当一个进程运行时，我们的数据库经常锁定，所以所有其他进程都在等待，直到当前进程完成。这是一个很大的问题，因为例如，在这种情况下，添加到购物车的过程也在等待，人们无法订购。

我们如何防止数据库被锁定这么长时间并解决这个问题？

服务器：

6x Intel Xeon
32GB RAM
500GB SSD

我的.cnf：

[mysqld]

bind-address = 127.0.0.1
local-infile=0
innodb_file_per_table=1
innodb_file_format=barracuda

slow_query_log = 1
slow_query_log_file=/var/log/mysql-log-slow-queries.log

key_buffer = 250M
key_buffer_size = 250M
max_allowed_packet = 128M
table_cache = 512
sort_buffer_size = 7M
read_buffer_size = 7M
read_rnd_buffer_size = 7M
myisam_sort_buffer_size = 64M
tmp_table_size = 190M
query_cache_type = 1
query_cache_size = 220M
query_cache_limit = 512M
thread_cache_size = 150
max_connections = 225
wait_timeout = 300
innodb_buffer_pool_size = 7G
max_heap_table_size =180M
innodb_log_buffer_size = 36M
join_buffer_size = 32M
innodb_buffer_pool_instances = 7

long_query_time = 15
table_definition_cache = 4K
open_files_limit = 60K
table_open_cache = 50767
innodb_log_file_size= 128M
innodb_lock_wait_timeout = 700

Answer 1

为您的 my.cnf [mysqld] 部分考虑的建议

以下带 # 的前导以禁用或 REMOVE 以允许默认值满足您的要求 Rick James 在之前的评论中已经提到了其中一些。

。 key_buffer . key_buffer_size .表缓存 .排序缓冲区大小 .读取缓冲区大小 . read_rnd_buffer_size . MyISAM_sort_buffer_size .加入缓冲区大小 . long_query_time . innodb_lock_wait_timeout

进行这些更改或将行添加到您的 my.cnf for

query_cache_type=0  # from 1  to turn OFF QC and conserve CPU cycles
query_cache_size=0  # from 220M to conserve RAM for more useful work
query_cache_limit=0  # from 512M to conserve RAM for more useful work
thread_cache_size=100  # from 150  V8 refman suggested CAP to avoid OOM
innodb_lru_scan_depth=100  # from 1024 to minimum to conserve CPU every SECOND
innodb_flush_neighbors=0  # from 1 no need to waste CPU cycles when using SSD
innodb_io_capacity_max=10000  # from 2000 since you have SSD
innodb_io_capacity=5000  # from 200 to use more of your SSD capability

如需更多帮助，请查看我的个人资料，单击网络个人资料以获取联系信息。

Answer 2

MySQL 将等待一定的时间来解除锁定，然后才会放弃并抛出该错误。如果您能够在一天中的任何一致时间跟踪看到这些错误消息的时间，您应该查看当时服务器正在执行的其他操作 - 例如正在运行的数据库备份。通过这样做，您应该能够缩小可能创建锁的进程的可能性，尽管它并不总是那么直截了当 - 可能需要一些试验和错误。

有时可能会导致数据库出现死锁问题。此问题背后的原因是，如果您正在运行大量自定义脚本并在数据库连接有机会关闭之前终止脚本。

如果您可以从 CLI 登录 MySQL 并运行以下命令

显示进程列表；

你会得到以下输出

+———+—————–+——————-+—————–+———+——+——-+——————+———–+—————+———–+
|      Id        |   User     |             Host             |       db       | Command | Time | State | Info | Rows_sent | Rows_examined | Rows_read |
+———+—————–+——————-+—————–+———+——+——-+——————+———–+—————+———–+
| 6794372 | db_user| 111.11.0.65:21532 | db_name| Sleep          | 3800 |          | NULL |          0       |          0                   |          0             |
| 6794475 | db_user| 111.11.0.65:27488 | db_name| Sleep         | 3757 |          | NULL |          0        |          0                   |          0             |
| 6794550 | db_user| 111.11.0.65:32670 | db_name| Sleep         | 3731 |          | NULL |          0        |          0                   |          0             |
| 6794797 | db_user| 111.11.0.65:47424 | db_name | Sleep         | 3639 |          | NULL |          0       |          0                   |          0             |
| 6794909 | db_user| 111.11.0.65:56029 | db_name| Sleep         | 3591 |          | NULL |          0       |          0                   |          0              |
| 6794981 | db_user| 111.11.0.65:59201 | db_name| Sleep         | 3567 |          | NULL |          0        |          0                   |          0             |
| 6795096 | db_user| 111.11.0.65:2390 | db_name| Sleep           | 3529 |          | NULL |          0        |          0                   |          0             |
| 6795270 | db_user| 111.11.0.65:10125 | db_name | Sleep         | 3473 |          | NULL |          0       |          0                   |          0             |
| 6795402 | db_user| 111.11.0.65:18407 | db_name| Sleep         | 3424 |          | NULL |         0         |          0                   |          0             |
| 6795701 | db_user| 111.11.0.65:35679 | db_name| Sleep         | 3330 |          | NULL |          0        |          0                   |          0             |
| 6800436 | db_user| 111.11.0.65:57815 | db_name| Sleep         | 1860 |          | NULL |          0       |          0                   |          0             |
| 6806227 | db_user| 111.11.0.67:20650 | db_name| Sleep         |  188 |          | NULL |          1        |          0                   |          0             |
| 6806589 | db_user| 111.11.0.65:36618 | db_name| Query        |   0    | NULL | SHOW PROCESSLIST |       0         |       0                 |       0       |
| 6806742 | db_user| 111.11.0.75:38717 | db_name| Sleep          |   0    |          | NULL |         0         |          0                    |          0            |
| 6806744 | db_user| 111.11.0.75:38819 | db_name| Sleep         |    0    |          | NULL |          61       |          61                  |          61         |
+———+—————–+——————-+—————–+———+——+——-+——————+———–+—————+———–+
15 rows in set (0.00 sec)

你可以看一个例子 6794372命令是sleep，时间是3800，这是阻止其他操作的。

这些进程应该使用命令一个一个地被杀死。

杀死 6794372；

一旦你杀死了所有的睡眠连接，一切应该会重新开始正常工作

Answer 3

这些已被弃用；他们的名字变了。删除它们：

key_buffer = 250M
table_cache = 512

这些都高于应有的水平：

key_buffer_size = 250M
query_cache_size = 220M
thread_cache_size = 150
long_query_time = 15
table_definition_cache = 4K
table_open_cache = 50767
innodb_lock_wait_timeout = 700

最后一个可能是反派。这意味着您有一些冗长的交易。这是您的代码中的设计缺陷。找到一种方法来缩短交易时间。如果您需要帮助，请描述您对我们所做的事情。

我觉得5 的交易时间很长。

你有时会这样吗？

ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction