Я выполнял процесс восстановления insert ignore into db1.Table (~140Gb) select * from db2.Table(~32Gb). The process took so long that I killed the query. Then did restart. On restart, mysqld starts first and does.

Мои таблицы в порядке, а конкретные таблицы не критичны.

Как остановить процесс восстановления? работает уже 1,5 дня. Некоторые сообщения error.log

Как мне убить / очистить page_cleaner или что-то еще, что делает восстановление? Я посмотрел, что делает page_cleaner, но не совсем понял. У меня нет каких-либо постоянных проблем с тем, как сервер работает, поэтому в идеале я не хотел бы менять какие-либо настройки.

Спасибо за вашу помощь!

@Wilson Hauck Жесткий диск - это традиционный диск. Версия MySQL - 5.7.27-0ubuntu0.16.04.1

Показать полный список процессов не имеет запущенных запросов

mysql> ПОКАЗАТЬ ГЛОБАЛЬНЫЕ ПЕРЕМЕННЫЕ, КАК '% size%';

mysql> SHOW GLOBAL VARIABLES like '%capacity%' ;
+------------------------+-------+
| Variable_name          | Value |
+------------------------+-------+
| innodb_io_capacity     | 200   |
| innodb_io_capacity_max | 2000  |
+------------------------+-------+
2 rows in set (0.00 sec)

Я не могу найти его в текущем error.log, но раньше я видел, что размер ~ 1045 МБ

результаты из top

**

Редактировать;

** убрал вопрос для удобочитаемости с помощью pastebin. Хороший сайт.

Немного предыстории того, что я делаю;

Дело не только в нехватке оперативной памяти, у меня процессор i3-3.7Ghz x2. Я не могу сейчас найти что-то лучшее.

Я записываю данные о производных финансовых инструментах. Мои записанные данные потока составляют примерно 7 ГБ к концу дня.

Я записываю данные в пустые таблицы и перемещаю таблицы в другую базу данных в конце дня, поэтому утром у меня могут быть пустые таблицы. Я управляю своими запросами с помощью union, когда мне нужно. Мое преимущество в том, что мои данные актуальны ближе к текущей дате. Мои алгоритмы не могут ждать запросов mysql и должны иметь информацию уже там, поэтому, когда мне нужны исторические данные, например. 30,60,90 средних значений и т. Д., У меня есть сводные таблицы для этого. Когда мне нужны непрерывные данные, которые обычно находятся в пределах 3 дней, я разделяю данные на 5 дней.

Моя текущая установка мне подходит. Мой конец рыночного дня, мое mysql потребление ОЗУ составляет около 6 ГБ, если мне не приходилось много смотреть на исторические данные, что обычно и бывает. Иногда бывает запаздывание, но позже в тот же день, и рынок уже в некотором роде оформился.

Проблема в page_cleaner . Это все еще не закончено.

Требуется дополнительная информация;

ПОКАЗАТЬ ГЛОБАЛЬНЫЙ СТАТУС;

ПОКАЗАТЬ ГЛОБАЛЬНЫЕ ПЕРЕМЕННЫЕ;

ПОКАЗАТЬ ПОЛНЫЙ СПИСОК ПРОЦЕССОВ; Поскольку сейчас рыночное время, нет смысла показывать full processlist;, так как в нем будут тонны длинных вставляемых sqls.

Полный отчет MySQLTuner: нет MySQLTuner

ПОКАЗАТЬ СТАТУС INNODB ДВИГАТЕЛЯ;

ulimit -a

iostat

Я наткнулся на этот ответ ищу 'как изменить innodb_log_file_size'. Подойдет ли мне предложенное удаление файла /var/lib/mysql/ib_logfile?

Обновить

Серевр разбился.

Я не получил ответа от вас, ребята, я увидел обновление для mysql и установил его. Я загружался, останавливался / запускался раньше и не думал, что применение обновления что-нибудь повредит. Я действительно надеялся, что это решит проблему.

Всю ночь пытался это исправить, но безуспешно. Всякий раз, когда я пытался переустановить Mysql, mysql-сервер выходил из-за ошибки, но mysqld работал, error.log становился 16-20 ГБ. Это само по себе заставит мою машину ползать. Думаю, если бы я подождал достаточно долго, он, возможно, смог бы отремонтировать себя, но я не мог больше ждать. Моя девелоперская работа остановлена.

Как только я понял, что таблицы волшебным образом не появятся снова, я установил MariaDb и некоторое время собирался попробовать.

Хотелось бы, чтобы был способ изолировать такие проблемы. Один стол повалил сервер.

Большое спасибо за ваше время и помощь. Я многому научился.

0
csaw 16 Ноя 2019 в 10:37
В настоящее время ваша система выглядит стабильной. Запрос дополнительной информации. Разместите на pastebin.com и поделитесь ссылками. Из корневого входа SSH текстовые результаты: B) ПОКАЗАТЬ ГЛОБАЛЬНЫЙ СТАТУС; минимум через 24 часа. C) ПОКАЗАТЬ ГЛОБАЛЬНЫЕ ПЕРЕМЕННЫЕ; D) ПОКАЗАТЬ ПОЛНЫЙ СПИСОК ПРОЦЕССОВ; заполните, пожалуйста E) заполните отчет MySQLTuner F) ПОКАЗАТЬ СТАТУС INNODB ДВИГАТЕЛЯ; И Необязательная очень полезная информация, если таковая имеется, включает - ulimit -a для списка лимитов linux / unix, iostat -xm 5 3 для IOPS по устройствам и количеству ядер / процессоров, для анализа настройки рабочей нагрузки сервера, чтобы предоставить предложения.
 – 
Wilson Hauck
17 Ноя 2019 в 21:32
Спасибо, что разместили большую часть запрошенной информации. Очистители страниц будут продолжать отображаться в журнале ошибок до тех пор, пока мы не внесем некоторые дополнительные изменения в вашу конфигурацию. MySQLTuner.com имеет Perl-скрипт, доступный для загрузки, который предоставит вам / нам еще один инструмент настройки / мониторинга. Отчет будет включать типы движков, количество таблиц и размер используемого хранилища данных. Ваш анализ находится в процессе с доступными данными.
 – 
Wilson Hauck
18 Ноя 2019 в 17:37
Отправьте сообщение на pastebin.com ТЕКСТОВЫЙ результат mpstat -P ALL 5 3, чтобы мы могли увидеть, сколько процессоров используется. Спасибо
 – 
Wilson Hauck
18 Ноя 2019 в 18:54
Заявление об отказе от ответственности; Я являюсь автором содержания веб-сайта, упомянутого в моем профиле, сетевом профиле, где у нас есть загружаемые БЕСПЛАТНЫЕ служебные скрипты, советы и контактная информация. Есть ли у вас возможность использовать Skype TALK? IO WAITS - БОЛЬШАЯ проблема. Вам определенно понадобится 48 ГБ дополнительной оперативной памяти (для максимального значения на вашем настольном процессоре), как рекомендуется как можно скорее.
 – 
Wilson Hauck
19 Ноя 2019 в 15:57
В какой стране и в каком часовом поясе вы находитесь?
 – 
Wilson Hauck
19 Ноя 2019 в 16:51

3 ответа

Восстановление было уже завершено, когда вы увидели в журнале такую ​​строку:

2019-11-16T03:07:35.985926Z 0 [Note] InnoDB: Apply batch completed

Через 10 секунд вы увидите это в журнале:

2019-11-16T03:07:45.962644Z 0 [Note] /usr/sbin/mysqld: ready for connections.

Это означает, что все работы по запуску были завершены, и MySQL был готов к нормальной работе.

Строки про очиститель страниц не являются частью восстановления. Очиститель страниц постоянно работает в InnoDB как обычная повседневная операция.

2019-11-16T03:15:39.226555Z 0 [Note] InnoDB: page_cleaner: 1000ms intended loop took 4545ms. The settings might not be optimal. (flushed=147 and evicted=0, during the time.)

Я опубликовал кучу подробностей об очистке страниц в своих ответах здесь:

Ваш innodb_buffer_pool_size 10 ГБ, вероятно, слишком мал. Только ваши db1.Table и db2.Table составляют 172 ГБ, и я не знаю, сколько у вас других таблиц или общий размер всех данных + индексов.

В моей работе мы стараемся поддерживать соотношение 1:10 по отношению к размеру пула буферов и общему размеру хранилища данных + индексов. Соотношение 1:10 - это не какая-то волшебная формула, это просто стандарт, который мы используем, чтобы увидеть, находится ли отношение буфера к хранилищу в разумном диапазоне для типичной рабочей нагрузки OLTP. Вы далеки от этого соотношения только с первыми двумя таблицами, которые вы упомянули.

Я также вижу, что ваш innodb_log_file_size составляет 48 МБ, что составляет размер по умолчанию для этой переменной в MySQL 5.7. Это означает, что вы, вероятно, никогда не настраивали эту переменную для своей рабочей нагрузки. Значение по умолчанию 48 МБ для журнала InnoDB ужасно занижено для производственных баз данных, которым необходимо обрабатывать большой объем записей. На моей работе мы увеличиваем это значение до 1 ГБ в экземплярах по умолчанию.

Каковы последствия такого маленького размера файла журнала? InnoDB должен сбрасывать страницы из пула буферов на диск, если в ОЗУ больше грязных страниц, чем может быть восстановлено файлом журнала в случае сбоя (или преднамеренного уничтожения, как вы). Эта промывка выполняется очистителем страниц.

Я думаю, у вас просто ужасно медленный жесткий диск, и он не успевает за скоростью записи, которую вы пытаетесь делать.

Это объясняет, почему ваш INSERT на 32 ГБ занял много времени. Он выполнял бы небольшую часть INSERT, создавая достаточно грязных страниц в буферном пуле, чтобы соответствовать размеру 48-гигабайтного файла журнала, затем InnoDB приостанавливал бы дальнейшие INSERT, пока он очищал грязные страницы.

Каждую 1 секунду page_cleaner пытается выбрать для очистки некоторое количество грязных страниц, достаточное для завершения за 1 секунду (это 1000 мс, упомянутые в строке файла журнала о page_cleaner). Но он не смог выполнить эту работу за 1 секунду, это заняло 4,5 секунды (4545 мс).

Он делает все, что может, в пределах ввода-вывода вашего медленного жесткого диска и низкого innodb_io_capacity (который на самом деле имеет размер, соответствующий жесткому диску). По сути, вы пытаетесь протолкнуть бочку с водой через трубу диаметром 1/2 дюйма, и вам интересно, почему это занимает так много времени!

Если у вас такая большая база данных, и вы выполняете операции, перемещающие по 10 ГБ за раз, вы должны ожидать, что технологии хранения, которой уже более 10 лет, потребуется некоторое время, чтобы это сделать.

Вот что я бы сделал:

  1. Перейдите на твердотельный накопитель с прямым подключением или хранилище NVMe. Не используйте жесткий диск для сервера базы данных.

  2. Увеличьте innodb_buffer_pool_size примерно до 1/10 размера ваших данных. Я предполагаю, что ваша рабочая нагрузка похожа на многие другие приложения, но, конечно, вам может потребоваться больший или меньший буферный пул в зависимости от вашего использования данных. Но из top я вижу, что у вас только 16 ГБ физической ОЗУ на вашем сервере, поэтому вам следует сначала обновить ОЗУ (другими словами, не превышайте выделение пула буферов относительно вашей физической ОЗУ).

  3. Увеличьте innodb_log_file_size до 1 ГБ, чтобы InnoDB не выполняла очистку так часто.

  4. Для копирования больших фрагменты данных, как и вы. Вместо того, чтобы копировать 32 ГБ данных в одном операторе SQL, упомянутый мною инструмент будет копировать небольшие подмножества данных из db2.Table, копируя их в db1.Table до тех пор, пока он не будет завершен. Таким образом, каждый «кусок» данных фиксируется быстро и не требует восстановления в случае сбоя. InnoDB будет счастливее, если вы сделаете транзакции небольшими и быстро их зафиксируете. Инструмент pt-archiver также выводит информацию о ходе копирования, поэтому у вас есть расчетное время его завершения. Этот инструмент бесплатный, он входит в пакет Percona Toolkit.

  5. Прекратите убивать вещи! Это не делает ничего быстрее.


Повторите вашу обновленную информацию.

Вы не можете изменить размер файла журнала innodb на работающем сервере MySQL, поэтому это значение доступно только для чтения. Вы должны изменить его в файле my.cnf, а затем перезапустить mysqld. Современные версии MySQL достаточно умны, чтобы изменить размер файлов журнала, а затем перезапустить себя снова, поэтому вам не нужно самостоятельно rm или mv файлы, как в старом ответе, который вы нашли.

ВНИМАНИЕ! Размер файла журнала можно изменить только после полного выключения . Если вы попытаетесь удалить файлы журнала после убийства mysqld, я гарантирую, что вы обязательно испортите свою базу данных!

Вам не нужно ждать завершения очистки страниц. Очиститель страниц всегда работает - это то, что я пытался вам сказать выше. Обычно он тихо работает в фоновом режиме. Вы можете прочитать об этом здесь: https: / /dev.mysql.com/doc/refman/5.7/en/innodb-buffer-pool-flushing.html

Причина, по которой очиститель страниц сообщает в журнале ошибок, заключается в том, что он не может завершить свою работу каждую секунду. Вы опубликовали iostat результатов, и я вижу, что вы ждете ввода-вывода в течение значительного времени. Вероятно, это твоя проблема.

Можно уменьшить скорость промывки можно контролировать. Вы уже снизили innodb_lru_scan_depth до минимума. Вы можете уменьшить innodb_io_capacity, у вас установлено значение 200 и его минимальное значение - 100. См. Мой ответ на Как устранить предупреждение mysql:" InnoDB: page_cleaner: предполагаемый цикл 1000 мс занял XXX мс. Настройки могут быть не оптимальными "? для объяснения.

На самом деле вам просто нужен более мощный сервер, если вы работаете с таким большим объемом данных.

2
Bill Karwin 18 Ноя 2019 в 18:25
Спасибо, что нашли время, чтобы помочь. ценить это. Я попытался установить innodb_log_file_size на 200 МБ, но он говорит, что значение только для чтения. Я добавил еще несколько деталей к вопросу.
 – 
csaw
18 Ноя 2019 в 11:12
Пожалуйста, посмотрите имена устройств iostat csaw. Насколько я понимаю, sda и sdb указывают тип устройства хранения SSD. Спасибо
 – 
Wilson Hauck
18 Ноя 2019 в 20:40
Имена устройств не имеют ничего общего с SSD. superuser.com/questions/558156 / what-does-dev-sda-for-linux-mean
 – 
Bill Karwin
18 Ноя 2019 в 21:52

В процессе восстановления было задействовано 1053 миллиона строк, которые подвергались очистке. Пусть работает, все будет сделано вовремя.

Замечания о времени, затрачиваемом очистителями страниц, можно свести к минимуму в разделе конфигурации [mysqld] с помощью

innodb_lru_scan_depth=100  # from 1024 to conserve 90% of CPU time used by function

Это может быть установлено с помощью

SET GLOBAL innodb_lru_scan_depth=100;    after login root in you MySQL Client
1
Wilson Hauck 17 Ноя 2019 в 16:42
Выходные почти закончились, а процесс все еще продолжается. Я изменил глубину сканирования, как было предложено, но мне бы очень хотелось, чтобы это закончилось. завтра мне снова нужно будет добавить данные из непрерывного потока, и я где-то читал, что одновременное чтение / запись плюс восстановление создает еще больше грязных страниц, следовательно, больше вещей, которые нужно очистить ...
 – 
csaw
17 Ноя 2019 в 11:21
Ваши данные хранятся на жестком диске, SSD или NVME? Что является результатом SELECT @@ version; Через 20 минут буду вне офиса на 3 часа.
 – 
Wilson Hauck
17 Ноя 2019 в 16:47
Не могли бы вы опубликовать результаты: A) ПОКАЗАТЬ ГЛОБАЛЬНЫЕ ПЕРЕМЕННЫЕ, КАК "% size%"; ? и B) ПОКАЗАТЬ ГЛОБАЛЬНЫЕ ПЕРЕМЕННЫЕ, такие как «% емкости»?
 – 
Wilson Hauck
17 Ноя 2019 в 16:50
Вы бы поступили правильно, если бы ничего не УБИВАЛИ, чтобы избежать дальнейших осложнений и повторной обработки. Вы имеете дело не с 1053 строками, а с 1053 миллионами строк, и это требует времени.
 – 
Wilson Hauck
17 Ноя 2019 в 16:55
1
Спасибо за попытку помочь. Очень цените ваше время. Выше разместил запрошенную информацию. Ничего не убил, решил, что mysql действительно не любит kill / hard reboot, на самом деле.
 – 
csaw
17 Ноя 2019 в 18:39

Rate Per Second = RPS - Предложения для вашего раздела my.cnf [mysqld]

innodb_fast_shutdown=0  # from 1 for CLEAN stop to avoid RECOVERY on start
max_connections=32  # from 151 because max_used_connections=7 to conserve RAM
read_rnd_buffer_size=128K  # from 256K to reduce handler_read_rnd_next RPS of 565
read_buffer_size=256K  # from 128K to reduce handler_read_next RPS of 478
innodb_flushing_avg_loops=5  # from 30 to reduce loop delay and innodb_buffer_pool_pages_dirty of 4,939

Убедитесь, что Hyper Thread выключен, в том числе в настройках BIOS. Этот URL-адрес может представлять ценность для вас https://askubuntu.com/questions/942728/disable- Hyper-threading-in-ubuntu

Держите нас в курсе, пожалуйста.

0
Wilson Hauck 19 Ноя 2019 в 17:27