- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Здравствуйте, коллеги.
Дано: 2 сервера master-slave. С базы с большими таблицами (2-3 ГБ).
Если реплицируется какой-либо тяжёлый запрос, который выполняется более 1 минуты, то затормаживается вся очередь репликации. С запросами, которые работают с загруженной таблицей всё понятно, но даже запросы, которые её не используют не могут выполниться, и встают в очередь.
Соответственно вопрос, можно как-то организовать репликацию в несколько потоков, или как с этой проблемой бороться?
Хм, 2-3 гб не так и много, а что у вас там за "сложные запросы" ? На которые по минуте уходит?
Соответственно вопрос, можно как-то организовать репликацию в несколько потоков, или как с этой проблемой бороться?
Если у вас хотя бы 5.1 и вы попробуете изменить построчный формат репликации (или наоборот на покомандный) , то те же самые запросы возможно будут реплицироваться быстрее. Лучше бы посмотреть на их природу.
запросами, которые работают с загруженной таблицей всё понятно, но даже запросы, которые её не используют не могут выполниться, и встают в очередь.
А вы уверены, что вам нужно именно репликацию ускорять, а не сервер ? Блокировки на серверах возникают не из-за репликации.
Очередь запросов в репликации тоже есть, но ее не так уж просто увидеть. Может, вы видите обычные блокировки в show processlist ?
Ну и многопоточную можно организовать. Зависит от того как вы мотивируете.
Некоторое время назад таблицы раздувались до 15 ГБ. И комманда delete from .. Where time < (последние три дня) выполняться могла довольно долго. Подобные таблицы используются не часто.. но на 3-4 часа репликацию вешать из-за неё нельзя!
Сервер Core-i7 920. С ним полный порядок. Просто запросов до 20 тыс в сек )
Смотрите в сторону ndb кластера
К сожалению он не подходит из-за особенностей выборок. Пытались его уже применить. Остановились пока на схеме master-master, и вцелом она нас устраивает, кроме этих моментов.
А диски как себя чувствуют? Может как раз их производительности и не хватает.
Некоторое время назад таблицы раздувались до 15 ГБ. И комманда delete from .. Where time < (последние три дня) выполняться могла довольно долго. Подобные таблицы используются не часто.. но на 3-4 часа репликацию вешать из-за неё нельзя!
Сервер Core-i7 920. С ним полный порядок. Просто запросов до 20 тыс в сек )
иногда проще переименовать большую таблицу (rename table ... to ...), создать новую со старым названием и структурой (create table ... like...) и скопировать в новую нужные данные из старой (insert into ... select * from ...), чем удалять миллионы строк из таблицы.
Bazis007, в вашем случае нужна регулярная ротация данных, например не delete from ... where > 3 дня, а delete ...... > 10 минут. Я думаю что тут можно оптимизировать чуток нагрузку.
Сейчас уже так и делаем, точнее написан скрипт который интеллектуально подбирает колличество строк для Limit, чтоб запрос за 5 сек не вылазил. Этот манёвр решил определённую часть проблем.
atop в среднем показывает 15-20 % нагрузки на диск. Сервер оптимизировали таким образом, чтоб оперативка использовалась по максимуму. Ну да, когда падает тяжёлый запрос то до 90% подскакивает, но такое бывает редко.
В целом задача стоит в том, чтоб такие вот запросы, не ставили раком всю репликаию. Нужно найти способ этот ньюанс обойти. Когда совсем всё плохо, можно переключить всю нагрузку на один из серверов, но делается это руками, и это не самый правильый выход. В общем вопрос открыт (
Перейти менеджер очередей не думали?