powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / MySQL [игнор отключен] [закрыт для гостей] / Отстает репликация - percona
18 сообщений из 18, страница 1 из 1
Отстает репликация - percona
    #38851734
Всем добрый день, нужна помощь

Имеется 2 сервера - один мощный с ssd, на котором выполняются все запросы, второй слабый - только для репликации БД и хранения статичных файлов. На обоих стоит percona

Intel Xeon E3-1270 3.5 ГГц, 32 ГБ DDR3, 2 x 240 ГБ SSD - master, здесь вся работа
Intel Atom Avoton C2758 2.4 ГГц, 8 ГБ DDR3, 2 x 1000 ГБ SATA - slave, здесь только репликация

Недавно слейв начал сильно отставать (текущее отставание - больше двух дней).

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 95.213.153.162
                  Master_User: repl
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.000262
          Read_Master_Log_Pos: 21227409
               Relay_Log_File: mysqld-relay-bin.000738
                Relay_Log_Pos: 52442916
        Relay_Master_Log_File: mysql-bin.000247
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
              Replicate_Do_DB:
          Replicate_Ignore_DB:
           Replicate_Do_Table:
       Replicate_Ignore_Table:
      Replicate_Wild_Do_Table:
  Replicate_Wild_Ignore_Table:
                   Last_Errno: 0
                   Last_Error:
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 52442770
              Relay_Log_Space: 1594779963
              Until_Condition: None
               Until_Log_File:
                Until_Log_Pos: 0
           Master_SSL_Allowed: No
           Master_SSL_CA_File:
           Master_SSL_CA_Path:
              Master_SSL_Cert:
            Master_SSL_Cipher:
               Master_SSL_Key:
        Seconds_Behind_Master: 185511
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error:
               Last_SQL_Errno: 0
               Last_SQL_Error:
  Replicate_Ignore_Server_Ids:
             Master_Server_Id: 1



Смотрю "show full processlist" на реплике - вижу там DELETE запросы к таблице table1 (там 1.9 млн записей). Вроде бы адекватные запросы, на мастере без проблем выполняются. Пробую делать банальный

Код: sql
1.
SELECT COUNT(*) FROM table1

- на мастере мгновенно (0.00 секунд), на слейве - 3-5 секунд. Причем если репликацию перед этим стопнуть - тоже мгновенно выполняется

top на слейве показывает что la в районе 1, память есть, wa - не больше 5%, iotop тоже не показывает никаких проблем
mysql стабильно занимает около 100% CPU (т.е. полностью одно ядро), место свободное есть

В связи с этим 2 вопроса:
a) куда дальше копать, как можно понять почему запросы которые быстро выполняются на бою медленно выполняются при репликации (понятна разница в конфигурации, но слишком сильная разница в выполнении)
б) таблица эта по большому счету не очень важна (это денормализованные данные, их по идее можно почистить), если стопнуть реплку, сделать TRUNCATE этой таблицы, а потом запустить репликацию снова - будут ли проблемы (последующие запросы ошибок давать не должны, они от данных в этой таблице не зависят)

---------------------------------------
С уважением, Каримбаев Тимур
...
Рейтинг: 0 / 0
Отстает репликация - percona
    #38851820
Фотография ScareCrow
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
авторa) куда дальше копать, как можно понять почему запросы которые быстро выполняются на бою медленно выполняются при репликации (понятна разница в конфигурации, но слишком сильная разница в выполнении)
explain ну и у перконы офигенная куча счетчиков
...
Рейтинг: 0 / 0
Отстает репликация - percona
    #38851824
netwind
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
авторIntel Xeon E3-1270 3.5 ГГц, 32 ГБ DDR3, 2 x 240 ГБ SSD - master, здесь вся работа
Intel Atom Avoton C2758 2.4 ГГц, 8 ГБ DDR3, 2 x 1000 ГБ SATA - slave, здесь только репликация

Репликация отстает потому что может. Тем более при такой существенной разнице в железе.
...
Рейтинг: 0 / 0
Отстает репликация - percona
    #38852010
ScareCrowавторa) куда дальше копать, как можно понять почему запросы которые быстро выполняются на бою медленно выполняются при репликации (понятна разница в конфигурации, но слишком сильная разница в выполнении)
explain ну и у перконы офигенная куча счетчиков

забыл я это написать: explain select разницы не показывает, explain delete-запроса на моей установке mysql не поддерживается

netwindРепликация отстает потому что может. Тем более при такой существенной разнице в железе.

я видимо плохо описал суть: мне как раз и надо было понять - почему на слейве delete-запросы выполняются медленно (т.е. куда смотреть). мне нужен был способ как понять почему на одном сервере медленно выполняются конкретные delete запросы, на довольно простой и небольшой таблице, с индексами, при неполной загрузке по ресурсам (на 100% занят CPU, причем на довольно простых запросах). я бы понял если бы дело было в диске, но тут ситуация явно не та, дисковой активности почти нет.

---
в общем проблема решена по второму варианту. почистил на слейве второстепенную таблицу на которой возникали проблемы, на текущий момент отставание разгреблось с 185к до 20к секунд
...
Рейтинг: 0 / 0
Отстает репликация - percona
    #38852014
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Тимур Каримбаевmysql стабильно занимает около 100% CPU (т.е. полностью одно ядро)Насколько я понимаю, именно сюда и упираетесь. Накат репликации работает в один поток и поэтому более одного ядра занять не может. А ядро медленное.
...
Рейтинг: 0 / 0
Отстает репликация - percona
    #38852019
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
miksoftА ядро медленное.Судя по http://ark.intel.com/products/77988/Intel-Atom-Processor-C2758-4M-Cache-2_40-GHz ядро не просто медленное, а очень медленное. Иначе 8 ядер и чипсет в TDP 20 W просто не запихнуть.
...
Рейтинг: 0 / 0
Отстает репликация - percona
    #38852022
miksoftТимур Каримбаевmysql стабильно занимает около 100% CPU (т.е. полностью одно ядро)Насколько я понимаю, именно сюда и упираетесь. Накат репликации работает в один поток и поэтому более одного ядра занять не может. А ядро медленное.

это я понимаю. мне нужно было разобраться "почему этот конкретный delete запрос тормозит на этом сервере" (т.е. почему именно он загоняет в эти 100%. В базе есть и другие таблицы, большие по объему, с ними тоже идет работа, но они вроде как не проскакивают в медленных). запрос несложный, delete.

Действительно сначала explain (я так и сделал), правда селекта - с ним все ок, быстро
Потом смотрел внешние ключи, убедиться никто не зависит от этой таблицы (т.е. по идее delete от селекта отличаться может тем что по внешним таблицам на предмет целостности проходится и там действительно может быть нагрузка на процессор) - нет, не оно.
Потом я попробовал остановить репликацию и оптимайзнуть таблицу - не помогло.
Потом стал смотреть диск - активность маленькая

На этом месте я решил что моих знаний mysql недостаточно (это не совсем моя область) для нормального анализа и полез на форум посоветоваться :)
...
Рейтинг: 0 / 0
Отстает репликация - percona
    #38852023
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Тимур Каримбаевexplain select разницы не показываетА сам explain можете показать?
Возможно, с ним на обоих серверах проблемы. Но первый вытягивает за счет могучего железа.
...
Рейтинг: 0 / 0
Отстает репликация - percona
    #38852031
miksoftmiksoftА ядро медленное.Судя по http://ark.intel.com/products/77988/Intel-Atom-Processor-C2758-4M-Cache-2_40-GHz ядро не просто медленное, а очень медленное. Иначе 8 ядер и чипсет в TDP 20 W просто не запихнуть.

http://habrahabr.ru/company/selectel/blog/230689/

судя по тому что что говорит селектел - производительность ядер отличается не так уж и сильно, раза в 4. по моим прикидкам при текущей загрузке мастера, и отсутствии другой загрузки реплики - на репликацию должно хватать с запасом (и всегда хватало).
господа, у меня нет вопроса в производительности железа (там много других цифр нужно будет смотреть), и нет ощущения что "один из серверов настолько медленнее другого что репликация обязана отставать" (выше описал почему)
...
Рейтинг: 0 / 0
Отстает репликация - percona
    #38852048
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Тимур Каримбаев,

Т.е. итоговая разница в производительности в 16 раз Вас не смущает?

Тимур Каримбаеви всегда хваталоТогда вспоминайте, с чего началось отставание. Возможно, резко вырос объем данных, изменились запросы/нагрузка, еще что-то...
...
Рейтинг: 0 / 0
Отстает репликация - percona
    #38852056
miksoftТимур Каримбаевexplain select разницы не показываетА сам explain можете показать?
Возможно, с ним на обоих серверах проблемы. Но первый вытягивает за счет могучего железа.

Похоже вы правы. Вчера в пылу разборок с железом не туда посмотрел. Начал сейчас смотреть логи mysql-клиента, я вчера это как-то упустил из виду (а сейчас после truncate сложно воспроизвести на слейве)

там был запрос вида


Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
select *  FROM `table1` WHERE f1 IN (SELECT id FROM table2 WHERE f2 = '157170');

+----+--------------------+---------------+-----------------+---------------------+---------+---------+------+---------+-------------+
| id | select_type        | table         | type            | possible_keys       | key     | key_len | ref  | rows    | Extra       |
+----+--------------------+---------------+-----------------+---------------------+---------+---------+------+---------+-------------+
|  1 | PRIMARY            | table1 | ALL             | NULL                | NULL    | NULL    | NULL | 1920485 | Using where |
|  2 | DEPENDENT SUBQUERY | table2        | unique_subquery | PRIMARY,f2 | PRIMARY | 4       | func |       1 | Using where |
+----+--------------------+---------------+-----------------+---------------------+---------+---------+------+---------+-------------+



при этом на table1.f1 висит индекс, но с результатами подзапроса он не срабатывает (кстати, пользуясь случаем спрошу - это нормально?). действительно более мощный сервер легко его проглатывал, даже с type=ALL

Сейчас переделал на JOIN - все гораздо проще оказалось

Код: sql
1.
2.
3.
4.
5.
6.
+----+-------------+-------+------+---------------------+-------------+---------+------------+------+-------+
| id | select_type | table | type | possible_keys       | key         | key_len | ref        | rows | Extra |
+----+-------------+-------+------+---------------------+-------------+---------+------------+------+-------+
|  1 | SIMPLE      | l     | ref  | PRIMARY,f2 | f2 | 4       | const      |   14 |       |
|  1 | SIMPLE      | ls    | ref  | PRIMARY,f1   | f1   | 4       | table2.id |  135 |       |
+----+-------------+-------+------+---------------------+-------------+---------+------------+------+-------+



спасибо!
...
Рейтинг: 0 / 0
Отстает репликация - percona
    #38852102
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Тимур Каримбаев
Код: sql
1.
IN (SELECT ... )

Не знаю как в Перконе, а в MySQL до версии 5.6 был баг оптимизатора, приводящий к тому, что вложенный селект вычислялся не один раз, а столько раз, сколько раз нужно было его проверить. Т.е. по числу записей в таблице `table1`. Поэтому крайне рекомендуется переписывать такие запросы через JOIN или EXIST, в зависимости от контекста.
...
Рейтинг: 0 / 0
Отстает репликация - percona
    #38852135
miksoftТимур Каримбаев
Код: sql
1.
IN (SELECT ... )

Не знаю как в Перконе, а в MySQL до версии 5.6 был баг оптимизатора, приводящий к тому, что вложенный селект вычислялся не один раз, а столько раз, сколько раз нужно было его проверить. Т.е. по числу записей в таблице `table1`. Поэтому крайне рекомендуется переписывать такие запросы через JOIN или EXIST, в зависимости от контекста.

мне казалось это совсем старый баг mysql (я просто mysql'ем не занимался уже несколько лет, сейчас приходится снова вникать, точно помню что там было раньше). в оптимизаторе вроде как перкона и mysql отличаться не должны

если бы на каждую запись из table1 выполнялся - было-бы совсем медленно (т.е. 1.9млн раз должен был выполниться). а тут впечатление такое что подзапрос выполняется 1 раз, но индекс не участвует, при этом проходит по всем 1.9 млн для сравнения с результатами подзапроса

в любом случае большое спасибо за помощь
...
Рейтинг: 0 / 0
Отстает репликация - percona
    #38852146
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Тимур Каримбаевмне казалось это совсем старый баг mysql (я просто mysql'ем не занимался уже несколько лет, сейчас приходится снова вникать, точно помню что там было раньше). в оптимизаторе вроде как перкона и mysql отличаться не должны

если бы на каждую запись из table1 выполнялся - было-бы совсем медленно (т.е. 1.9млн раз должен был выполниться). а тут впечатление такое что подзапрос выполняется 1 раз, но индекс не участвует, при этом проходит по всем 1.9 млн для сравнения с результатами подзапроса

в любом случае большое спасибо за помощьСудя по слову DEPENDENT в плане, баг все еще присутствует.
Кстати, непонятно, почему был выбран индекс PRIMARY. По идее, индекс f2 должен быть более полезным. Но не видя DDL таблицы нельзя утверждать что-то наверняка.
...
Рейтинг: 0 / 0
Отстает репликация - percona
    #38852178
alex564657498765453
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
netwindавторIntel Xeon E3-1270 3.5 ГГц, 32 ГБ DDR3, 2 x 240 ГБ SSD - master, здесь вся работа
Intel Atom Avoton C2758 2.4 ГГц, 8 ГБ DDR3, 2 x 1000 ГБ SATA - slave, здесь только репликация

Репликация отстает потому что может. Тем более при такой существенной разнице в железе.

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

а вот слейву тяжелее...ему надо делать выборки, притом учитывать кучу моментом с апдейтами... если провести аналогию с сервером свн, то твоя машина это сервер, где обрабатываються изменения, а сервер свн это слейв, который другим всем на команды апдейт выдаёт новую версию данных. (при условии что другие не меняют ничего...только читают, как клиенты слейва базы данных)
...
Рейтинг: 0 / 0
Отстает репликация - percona
    #38852194
alex564657498765453netwindпропущено...


Репликация отстает потому что может. Тем более при такой существенной разнице в железе.

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

а вот слейву тяжелее...ему надо делать выборки, притом учитывать кучу моментом с апдейтами... если провести аналогию с сервером свн, то твоя машина это сервер, где обрабатываються изменения, а сервер свн это слейв, который другим всем на команды апдейт выдаёт новую версию данных. (при условии что другие не меняют ничего...только читают, как клиенты слейва базы данных)

очень странное предположение (не говорю что неверное)

> ибо ему то что...пришла команда на изменение, максимум оповестил все слейвы, и делает себе штатно изменение
во-первых мастер, в отличие от слейва, должен учитывать транзакционность. т.е. параллельно открытые транзакции и т.п.
на слейв можно отгрузить только закоммиченные изменения

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

> а вот слейву тяжелее...ему надо делать выборки
это еще почему? в нашей ситуации мастеру как раз нужно делать выборки, слейву - нет
...
Рейтинг: 0 / 0
Отстает репликация - percona
    #38852229
netwind
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
alex564657498765453netwindпропущено...


Репликация отстает потому что может. Тем более при такой существенной разнице в железе.

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


Мне не понятно. По-моему это неверно.

автора вот слейву тяжелее...ему надо делать выборки
Вы, видимо, хотели сказать о ситуации когда при старте репликации до завершения "прогрева" те же запросы работают медленнее.
Да, это запросто. Есть специальный скрипт - mk-slave-prefetch. Он призван поднимать данные перед тем как будут запускаться запросы на модификацию. И, причем, параллельно в несколько потоков, что в некотором смысле может выжать из подчиненного больше чем обычно. Но это все надо проверять для конкретной ситуации. Я не использовал, просто знаю об этом.
...
Рейтинг: 0 / 0
Отстает репликация - percona
    #38853097
Фотография ScareCrow
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
говорят в 5.6 у перконы появилась "multi threaded slave"
...
Рейтинг: 0 / 0
18 сообщений из 18, страница 1 из 1
Форумы / MySQL [игнор отключен] [закрыт для гостей] / Отстает репликация - percona
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]