Pull to refresh

Comments 9

Замечания:
1) коннект к мусклу вызывался каждый раз специально чтобы посмотреть на этот параметр;
2) если коннект вынести за предел цикла, то ситуация не сильно меняется;
3) в тесте 3 ситуация будет совершенно иная в рабочей ситуации, так как оверхед mysql-proxy будет перекрываться за счет шардинга
какая версия mysql-proxy? где комплексные замеры остальных параметров? munin хотя бы влепили бы.
есть мнение, что все дело в однопоточной модели mysql-proxy версий ниже 0.8.
«mysql-proxy — практически идеальное решение для тех, кому нужен дешевый шардинг без переписывания приложений, а также хостинг провайдерам, которым сложно контролировать криворуких клиентов»

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

навскидку я приведу вам парочку примеров «из жизни», от которых ваши администраторы станут спать ещё меньше, а пользователи начнут писать ещё чаще

1. лаг репликации
2. SELECT LAST_INSERT_ID()/mysql_insert_id()

это только вершина айсберга, но уже эти проблемы вы не сможете решить без переписывания кода.
Скрипт из поставки rw-splitting.lua вроде бы специальным образом обрабатывает эти штуки. Но автор пишет, что со скриптами еще хуже масштабирование. в 0.9 обещает улучшить.

С репликацией, конечно, возможен облом, но думаете ушлых хостеров это остановит? Во многих случаях может нормально работать.
угу, я тоже читал (правда давно), что проблемы типа получения last_insert_id() скриптом решаются, но я верю, что всё равно остаётся ряд аналогичных проблем, когда даже в той же сессии читать нужно из мастера, а скрипт об этом не знает.
Объясните пожалуйста в чем великая плюшка разделения запросов на запись и на чтение по разным серверам? Проблемы такого подхода очевидны, а в чем преимущества?

По моему master-master репликация плюс балансировка на уровне соединений а не запросов гораздо более жизнеспособная схема.

Правда более чем на 2-х машинках я ее не разворачивал, но в теории должно работать. Вот только каждый новый мускуль добавленый в такое колечко репликации создает точку отказа.
4 тест. 1000 записей — это очень маленький объем данных для состоятельной оценки. Думаю mysql на слейве просто закешировал данные после третьего теста и в 4 отдал его вам быстрее.
Sign up to leave a comment.

Articles