LINUX.ORG.RU
ФорумAdmin

MariaDB 10.3 нештабильна

 , , , ,


0

1

Привет!

Имею Ubuntu 16.04.5 с говносайтами, LEMP стек, AppArmor отключил и удалил.

Тем не менее, MariaDB 10.3 периодически любила падать на ровном месте. Закономерности как таковой не было, почему она ложилась. Но, что самое обидное на MySQL Community Server 5.7 все работает без нареканий. Логов я вам не покажу, потому что у вас документов нету я их просто не сохранил.

Конфиг привожу ниже.

Мой вопрос сталкивались ли вы с такими вот самопроизвольнымими «обмороками»?

Версия MariaDB последняя доступная на данный момент из их официального PPA официального репозитория


[client]
port=3306
socket=/var/run/mysqld/mysqld.sock

[mysqld_safe]
socket=/var/run/mysqld/mysqld.sock

[mysqld]
user=mysql
pid-file=/var/run/mysqld/mysqld.pid
socket=/var/run/mysqld/mysqld.sock
port=3306
basedir=/usr
datadir=/var/lib/mysql
tmpdir=/tmp
lc-messages-dir=/usr/share/mysql
log_error=/var/log/mysql/error.log

symbolic-links=0
  
skip-external-locking
key_buffer_size = 16M
max_allowed_packet = 16M
table_open_cache = 64
sort_buffer_size = 512K
net_buffer_length = 8K
read_buffer_size = 256K
read_rnd_buffer_size = 512K
query_cache_limit = 8M
join_buffer_size = 1M
query_cache_type = 0
query_cache_size = 0
myisam_sort_buffer_size = 8M

#innodb_use_native_aio = 0
innodb_file_per_table
innodb_log_file_size = 16M
innodb_buffer_pool_size = 1280M
innodb_flush_log_at_trx_commit = 2
innodb_flush_method = O_DIRECT
performance_schema = on
max_connections=70
max_user_connections=30
wait_timeout=10
interactive_timeout=50
long_query_time=5

!includedir /etc/mysql/conf.d/

Обидно, вроде бы как Мария позиционирует себя как «бесшовная» замена Мускулю, а мне такой ГейзенБаг попался...

P.S. Добавил тег systemd

★★★★★

Последнее исправление: Twissel (всего исправлений: 2)

Версия MariaDB последняя доступная на данный момент из их официального PPA

Удивился: что за «официальный PPA». Посмотрел на сайте MariaDB - нет там PPA, есть deb-пакет.

Partisan ★★★★
()

Мне когда-то дали совет, пользуйся мол только четными версиями релизов. Совет ещё ни разу не проводил.

anonymous
()
Ответ на: комментарий от macumazan

ЧСХ, таблицы у меня все были целы, я тогда проверял.

Больше было похоже на криво написанный юнит для systemd, т.е. сервис перезапускался, но не сообщал об этом systemd, в результате ненужнод убивал его по таймауту. Или это просто какая-то НЁХ.

Надо глянуть сабжевый багтрекер.

Twissel ★★★★★
() автор топика
Последнее исправление: Twissel (всего исправлений: 1)
Ответ на: комментарий от anonymous

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

Deleted
()
Ответ на: комментарий от Deleted

Специально для тебя, на то время в логах было чисто. От слова совсем Т.е. похоже, что PID 1 не получал отклика от службы БД.

Twissel ★★★★★
() автор топика
Ответ на: комментарий от darkenshvein

Timeout exceeded, no response from service Что-то в это духе От системд, хотя процесс себе спокойно работал.

Twissel ★★★★★
() автор топика

MariaDB 10.3, Ubuntu 16.04, MySQL 5.7

А почему MariaDB раиспоследняя, а остальное — нет?

Если охота пердолинга, так и ставь Ubuntu Server 18.10 + MySQL 8

Ну и PHP обязательно нараиспоследний 7.2

fornlr ★★★★★
()
Последнее исправление: fornlr (всего исправлений: 1)
Ответ на: комментарий от fornlr

Троллишь ты толсто и глупо) Очевидно, потому что с предыдущими версиями (10.1, 10.2) все падало таким же образом только раз в сутки.

Ну 10.3, примерно раз в 2 недели.

И да, php действительно 7.2, полёт нормальный.

Так что, толсто и непитательно.

Twissel ★★★★★
() автор топика
Последнее исправление: Twissel (всего исправлений: 1)
Ответ на: комментарий от Twissel

Очевидно, потому что с предыдущими версиями (10.1, 10.2) падали таким же образом раз в сутки.

С какого места, это очевидно? Это сразу писать ✍️ надо

fornlr ★★★★★
()

Короче говоря, втулю на выходных Марию на тот сайт, который не очень важен и приду сюда с логами.

Twissel ★★★★★
() автор топика
Последнее исправление: Twissel (всего исправлений: 1)
Ответ на: комментарий от fornlr

Это сразу писать ✍️ надо

Согласен. Ну вот с того места, где я сижу очевидно, что очевидно :-)

Twissel ★★★★★
() автор топика
Ответ на: комментарий от Twissel

Мне неочевидно, что эти баги вообще какое-то отношение имеют к твоей проблеме.

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

+1, логи на момент креша где?

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от intelfx

Логи будут с недели.

Меня больше интересовало твое мнение как systemd-евангелиста, насколько разумное решение проблемы предлагается здесь?

Я бы даже не создавал этот топик, но заказчику сказали, что MariaDB крутая и пошло-поехало. А теперь мне самому стали интересно — в чем же собственно дело, просто на проде я больше таких экспериментов ставить не буду :-)

Twissel ★★★★★
() автор топика
Последнее исправление: Twissel (всего исправлений: 1)
Ответ на: комментарий от Twissel

Меня больше интересовало твое мнение как systemd-евангелиста

Моё мнение как systemd-евангелиста следующее: «Кошка бросила котят — это Путинsystemd виноват».

intelfx ★★★★★
()
Ответ на: комментарий от Twissel

насколько разумное решение проблемы предлагается здесь?

Повторяю вопрос: с чего ты взял, что эти багрепорты имеют какое-то отношение к твоей проблеме?

intelfx ★★★★★
()
Ответ на: комментарий от intelfx

Ну вот будут логи, тогда и поговорим.

Интуиция.

Twissel ★★★★★
() автор топика
Ответ на: комментарий от intelfx

Т.е. вместо конструктивного обсуждения у тебя позиция скрытно-воинствующего аполегета, который отрицает возможные проблемы и недоработоки в systemd? :-D

И комментарии в баг-трекере ты не читаешь из принципа?

Twissel ★★★★★
() автор топика
Ответ на: комментарий от Twissel

И комментарии в баг-трекере ты не читаешь из принципа?

Похоже, это как раз ты не читаешь баг-репорты дальше слова «systemd».

Т.е. вместо конструктивного обсуждения у тебя позиция

В рамках конструктивного обсуждения альфа-тестирования libastral.so.0 моя позиция следующая: я не вижу, каким образом связаны проблема по ссылке (любой из) и проблема в ОП.

скрытно-воинствующиего аполегета, который отрицает возможные проблемы и недоработоки в systemd? :-D

Ок, проехали. Разберёшься — скастуй.

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 2)
Ответ на: комментарий от intelfx

Проехали.

Будут логи и конкретика, позову.

Twissel ★★★★★
() автор топика

Мой вопрос сталкивались ли вы с такими вот самопроизвольнымими «обмороками»?

Нет. Перешёл на MariaDB 4 года назад, использую на полудюжине живого железа и в дюжине контейнеров (Docker/LXC), самая жирная база около 50Гб и до 1000 запросов в секунду. Ни разу не падала. Ubuntu, начиная с 14.04 по 18.04

KRoN73 ★★★★★
()

Позавчера поставил MariaDB на другой сайт, где не очень важен uptime.

Пока критических ошибок нет. Только

2018-10-19 14:39:32 46 [Warning] Aborted connection 46 to db: 'admin_gardener_db' user: 'admin_gardener' host: 'localhost' (Got timeout reading communication packets)

Конфиг

[client]
port=3306
socket=/var/run/mysqld/mysqld.sock

[mysqld_safe]
socket=/var/run/mysqld/mysqld.sock

[mysqld]
bind-address=localhost
user=mysql
pid-file=/var/run/mysqld/mysqld.pid
socket=/var/run/mysqld/mysqld.sock
port=3306
basedir=/usr
datadir=/var/lib/mysql
tmpdir=/tmp
lc-messages-dir=/usr/share/mysql
log_error=/var/log/mysql/error.log

symbolic-links=0

skip-external-locking
key_buffer_size = 16K
max_allowed_packet = 1M
table_open_cache = 8152K
sort_buffer_size = 64K
read_buffer_size = 256K
read_rnd_buffer_size = 256K
net_buffer_length = 2K
thread_stack = 240K

#innodb_use_native_aio = 0
innodb_file_per_table

max_connections=30

max_user_connections=25
wait_timeout=10
interactive_timeout=50
long_query_time=5

!includedir /etc/mysql/conf.d/

Продолжаю наблюдение, обычно сюрпризы начинались после 10 дней аптайма.

Twissel ★★★★★
() автор топика
Ответ на: комментарий от KRoN73

Кстати тогда же (позавчера) у меня на Арубе почему-то отпали итальянские зеркала Убунты, заменил на украинские — все завелось)

Twissel ★★★★★
() автор топика
Ответ на: комментарий от Twissel

обычно сюрпризы начинались после 10 дней аптайма.

А на ссайт с таким конфигом вообще кто-нибудь ходит? Или одного семрашевского бота хватит чтоб поставить это изделие в позу раком?

LynxChaus
()
Ответ на: комментарий от LynxChaus

Или одного семрашевского бота хватит чтоб поставить это изделие в позу раком?

Вот с этого места поподробнее :-)

Ходють, ходють и боты в том числе. Но т.к. аптайм того сайта мне не сильно важен, я там и тренируюсь :-)

Twissel ★★★★★
() автор топика
Ответ на: комментарий от anonymous

Там, где были сюрпризы, там они были именно с конфигом от mysqltuner'а.

Но дело не в этом. Видно, то все-таки был Гейзенбаг.

Т.к. сейчас на тестовой vps-ске сабж под systemd нормально стартует/перезапускается.

Twissel ★★★★★
() автор топика
Ответ на: комментарий от anonymous

О, вот за это спасибо.

Это один из немногих толковых ответов.

Twissel ★★★★★
() автор топика
Ответ на: комментарий от LynxChaus

https://dev.mysql.com/doc/refman/5.7/en/server-system-variables.html#sysvar_m...

https://dev.mysql.com/doc/refman/5.7/en/server-system-variables.html#sysvar_m...

Сходу противоречия не вижу, но первое значение увеличу :-)

И да на сайте-визитке пока ваще не падает

P.S. точнее второй параметр удалил, а в первом увеличил значение.

Twissel ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.