Модераторы: skyboy, SamDark
  

Поиск:

Ответ в темуСоздание новой темы Создание опроса
> MariaDB - Записи в БД появляются с задержкой 15 ми 
:(
    Опции темы
ZoranM
Дата 19.12.2017, 13:48 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Новичок



Профиль
Группа: Участник
Сообщений: 4
Регистрация: 19.12.2017

Репутация: нет
Всего: нет



Добрый день.

Подскажите пожалуйста, установлена mariaDB Galera 10.1 на CentOS 7.1. 
В БД пишутся данные, с веб.форм (20-30 ПК) 
На 1 ПК эти формы распечатываются.

Иногда возникает ситуация, когда человек заполнил форму, подошел за распечаткой, но его данных в БД нет.
Ни запросы на печать не видят данных, ни запросы через SQLyog их не видят. Данные посетителя появляются через 10-15 мин.

Не смотря на наличие Galera используется пока 1 сервер. 
Проблема наблюдалась и ранее, когда стоял только 1 сервер mySql.

Грешили на Кэш, но сейчас установлено:
##cache
query_cache_size=0
query_cache_type=0


Явных транзакций нет. 1 запрос на сохранение, 1 на выборку из этой же таблицы.
настройка сервера: transaction-isolation = READ-COMMITTED

Параллельно все запросы пишутся в таблицу Логов. Запросов на чтение к ней нет. Только на вставку. И база это другая на том же сервере.
Но данных посетителя нет и в этой таблице. Проверяю запросом через SQLyog .

Подскажите идеи, на что это похоже, как повторить и какие параметры покрутить. Проблема появляется при относительно "большой" нагрузке, хотя 20-30 записей на вставку в минуту большой нагрузкой не назовешь, но все же. Хотелось бы понять хотя бы в каком направлении искать проблему.

Сохранение и получение данных идет через модуль PHP+PDO. С клиента запросы точно ушли. (Клиент в ответ получил подтверждение об отсутствии ошибок при сохранении)
При этом пропадают не все запросы. 1 посетитель не напечатался, но другие в основном продолжают нормально распечатываться, хотя делали запрос уже позже. Бывает к этому присоединяется еще несколько человек "ожидающих" .
Фронтэндов с PHP 2. Обращаются к 1 базе. Внутри транзакций нет, сессий тоже нет. Просто полученный набор параметров от формы сохраняют в Бд 1 командой insert.


Заранее спасибо. Готов ответить на "наводящие" вопросы.


PM MAIL   Вверх
Akina
Дата 19.12.2017, 14:49 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Советчик
****


Профиль
Группа: Модератор
Сообщений: 20393
Регистрация: 8.4.2004
Где: Зеленоград

Репутация: 106
Всего: 449



А что на этот счёт думают логи - генеральский и медленный?
И, если после сохранения человеку доступен просмотр своих сохранённых данных - он их реально видит? А после рестарта приложения? а после рестарта компа?


--------------------
 О(б)суждение моих действий - в соответствующей теме, пожалуйста. Или в РМ. И высшая инстанция - Администрация форума.

PM MAIL WWW ICQ Jabber   Вверх
ZoranM
Дата 19.12.2017, 15:55 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Новичок



Профиль
Группа: Участник
Сообщений: 4
Регистрация: 19.12.2017

Репутация: нет
Всего: нет



К сожалению логов нет никаких. Пути прописаны, но файлов нет. Почему не знаю. Админы будут разбираться, это отдельная тема, возможно.
На данный момент их просто нет. (По крайней мере в прописанной папке /var/log/mysql/)

Человек не смотрит свои данные. Он заполнил форму, нажал Сохранить. Клиент отправляет запрос на сохранение по HTTPS. При получении ответа OK посетителю выводится сообщение - пройдите и получите бланк заказа. Он подходит, но бланк не печатается. 
Сотрудники обращаются в тех.поддержку. Пытаемся на моменте разобраться. Бывает, конечно, что чел ошибся в написании фамилии или ник указал, потом не услышал и т.д. Т.е. бланк находим и печатаем. Но в данных случаях в БД нет данных. Причем нет как в таблице заказов, так и нет в БД логов.

Человеку делается новая форма заказа, печатается. Он уходит. А через 5-15 мин клиент печати выплевывает эти бланки. Т.е. в принципе ничего не пропадает.
Я бы предположил что дело в транзакциях, но явно их нет, и операции достаточно простые.
Возможно случается какой-то deadlock, но какой и почему - тоже непонятно. 

рестарт приложения или компа (клиента) никак не влияет. 

К слову сам сервер и БД находятся под нагрузкой. Идет 1000-2500 запросов в минуту. в PHP/Apache логах особо ничего не поймешь. Потому и пытаюсь понять что конкретно нужно искать. 
Это явно не ошибки SQL, т.к. данные потом появляются.
PM MAIL   Вверх
Akina
Дата 19.12.2017, 21:00 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Советчик
****


Профиль
Группа: Модератор
Сообщений: 20393
Регистрация: 8.4.2004
Где: Зеленоград

Репутация: 106
Всего: 449



Цитата(ZoranM @  19.12.2017,  16:55 Найти цитируемый пост)
Клиент отправляет запрос на сохранение по HTTPS. При получении ответа OK посетителю выводится сообщение - пройдите и получите бланк заказа.

То есть имеется веб-сервер и скрипт-сервер, кроме всего прочего - а у них тоже есть логи.
Но я считаю, этой проблемой (вернее, мониторингом для получения данных по инцидентам) должен заняться DBA сервера БД.
Цитата(ZoranM @  19.12.2017,  16:55 Найти цитируемый пост)
Возможно случается какой-то deadlock

Вряд ли - дедлоки, как и беременность, сами не рассасываются.


--------------------
 О(б)суждение моих действий - в соответствующей теме, пожалуйста. Или в РМ. И высшая инстанция - Администрация форума.

PM MAIL WWW ICQ Jabber   Вверх
ZoranM
Дата 22.12.2017, 11:01 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Новичок



Профиль
Группа: Участник
Сообщений: 4
Регистрация: 19.12.2017

Репутация: нет
Всего: нет



Цитата(Akina @  19.12.2017,  21:00 Найти цитируемый пост)
То есть имеется веб-сервер и скрипт-сервер, кроме всего прочего - а у них тоже есть логи.

Да, имеется веб-сервер. Логи есть. В логах ошибок нет. 


Цитата(Akina @  19.12.2017,  21:00 Найти цитируемый пост)
 должен заняться DBA 

DBA - это Администратор? Он ей и занимает. Но ситуация абсолютно не понятна. Настройки вроде все в соответствии с рекомендациями.
По-тому и пытаемся выяснить возможные варианты действий для локализации проблемы у широкого сообщества. Опыт же у всех разный. 

Данные точно сохраняются. И точно в то время, когда они были сохранены. Порядковый ID и Дата/время сохранения соответствуют фактическому времени. И данные через 10-15 мин становятся видны через запросы.
Непонятно почему происходит такая задержка "видимости" при обращении к данным.
PM MAIL   Вверх
Akina
Дата 22.12.2017, 11:18 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Советчик
****


Профиль
Группа: Модератор
Сообщений: 20393
Регистрация: 8.4.2004
Где: Зеленоград

Репутация: 106
Всего: 449



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


--------------------
 О(б)суждение моих действий - в соответствующей теме, пожалуйста. Или в РМ. И высшая инстанция - Администрация форума.

PM MAIL WWW ICQ Jabber   Вверх
ZoranM
Дата 22.12.2017, 13:32 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Новичок



Профиль
Группа: Участник
Сообщений: 4
Регистрация: 19.12.2017

Репутация: нет
Всего: нет



Мы тоже грешили на кэш запросов. Но сейчас он отключен.

"Видимость" данных я проверяю с двух подключений: с веб сервера запросом и прямым подключением к базе через SQLyog. С обоих подключений данные не видны.
Консольным клиентом попробуем, спасибо за идею.

Может ли дисковый кэш так влиять?
Какой еще кэш может быть? 

PM MAIL   Вверх
Google
  Дата 26.5.2019, 06:37 (ссылка)  





  Вверх
  
Ответ в темуСоздание новой темы Создание опроса
1 Пользователей читают эту тему (1 Гостей и 0 Скрытых Пользователей)
0 Пользователей:
« Предыдущая тема | MySQL | Следующая тема »


 




[ Время генерации скрипта: 0.0622 ]   [ Использовано запросов: 21 ]   [ GZIP включён ]


Реклама на сайте     Информационное спонсорство

 
По вопросам размещения рекламы пишите на vladimir(sobaka)vingrad.ru
Отказ от ответственности     Powered by Invision Power Board(R) 1.3 © 2003  IPS, Inc.