MySQL сервер ушел на ОБНОВЛЕНИЕ (Огромный QUERY, около 85 МБ), используя mysli PHP

0

Я знаю, что этот вопрос был опубликован/задан много раз, и было дано много ответов. Однако, насколько мне известно, никто из них, похоже, пока не работает.

Итак, вот в чем проблема: при обновлении по ОГРОМНОМУ запросу ~ 85 МБ для одного запроса UPDATE (просьба избавить меня "вы должны пересмотреть свой дизайн базы данных", а не по выбору), PHP дает мне следующую ошибку: сервер MySQL ушел далеко.

Теперь это соединение является локальным (~ 5 секунд для передачи 85 МБ) (Большая часть запроса обновляет поле LONGTEXT)

Вот моя настройка:

1 экземпляр Docker с запуском APACHE + PHP 7 1 экземпляр Docker с запуском mysql 5.7

my.cnf

[mysqld]
datadir=/var/lib/mysql
socket=/mysql.sock
user=root
# Disabling symbolic-links is recommended to prevent assorted security risks
symbolic-links=0
innodb_file_per_table=1
ft_min_word_len=1
max_allowed_packet=1G

innodb_buffer_pool_size=1024M
innodb_log_file_size=512M
max_connections=10000
query_cache_size=128M
skip_name_resolve
bind-address = 0.0.0.0
sql_mode="STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION"

interactive_timeout = 9999
wait_timeout = 9999
innodb_lock_wait_timeout = 9999
net_read_timeout = 9999
net_write_timeout = 9999
explicit_defaults_for_timestamp = TRUE
connect_timeout = 1000000
net_buffer_length = 256M

[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid
innodb_file_per_table=1
ft_min_word_len=1
max_allowed_packet=1G

innodb_buffer_pool_size=1024M
innodb_log_file_size=512M
max_connections=10000
query_cache_size=128M
skip_name_resolve
bind-address = 0.0.0.0

interactive_timeout = 9999
wait_timeout = 9999
innodb_lock_wait_timeout = 9999
net_read_timeout = 9999
net_write_timeout = 9999
explicit_defaults_for_timestamp = TRUE
connect_timeout = 1000000
net_buffer_length = 256M


[mysqldump]
max_allowed_packet = 1G

(Я знаю, что MySQL работает как root, и это плохая практика)

Я также пробовал с & без

mysqli.reconnect = On

в моем php.ini, но не работал.

Есть ли какие-то варианты, о которых я не знаю?

Еще раз спасибо за ваше время на такую общую проблему.

  • 0
    какой фактический запрос?
  • 0
    ОБНОВЛЕНИЯ invoices SET serialized_infos = '[85 МБ base64]' ГДЕ idx = 3
Теги:

2 ответа

1
Лучший ответ

Понял ! Преступлением было сжатие mysql: https://dev.mysql.com/doc/refman/5.7/en/gone-away.html

Удалено сжатие, и все работает! :) - Этот ответ должен быть всем известен, чтобы избежать нескольких часов чистых головных болей -

Поделиться
  • 0
    В этом конкретном случае, нет, не было. Это в комментарии ниже фактического руководства. Это действительно ошибка от MySQL.
0

Похоже, у вас слишком короткий тайм-аут для сокетов. Измените php.ini или обманите ini_set. Могут быть слишком низкими значениями в mysql для размера запроса.

Чтобы вставить большой запрос mysql, вы должны настроить как mysql, так и php

PHP:

  1. memory_limit
  2. max_execution_time

MySQL:

Проверьте настройки, чтобы они были достаточно большими:

  1. max_allowed_packet
  2. wait_timeout
  3. Для innodb: innodb_log_file_size
Поделиться
  • 0
    Mysql: | wait_timeout | 9999 | max_allowed_packet | 1073741824 | | slave_max_allowed_packet | 1073741824 |
  • 0
    Хорошо, это более 1 ГБ, что хорошо. Не могли бы вы также проверить wait_timeout ?
Показать ещё 11 комментариев

Ещё вопросы

Сообщество Overcoder
Наверх
Меню