Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 15
Так всё-таки, почему PXC, а не Galera?
У нас уже был опыт использования продуктов от Percona, причем вполне успешный. Нас устраивает их скорость выпуска багфиксов и портирования патчей из апстрима. К тому же они русскоязычные и продают поддержку. Если нам понадобится помощь всегда можно купить у них поддержку их продукта.
Во-вторых у них есть некоторые патчи на Galera Cluster, которые делают его поддержку более простой (например strict_mode, который не даст выполнить потенциально опасные операции на кластере).
Во-вторых у них есть некоторые патчи на Galera Cluster, которые делают его поддержку более простой (например strict_mode, который не даст выполнить потенциально опасные операции на кластере).
Почему не рассматривали балансировку на MaxScale?
По тестам от Percona MaxScale медленнее ProxySQL в fast-forward режиме процентов на 10-20%. Учитывая это и то, что нам важна задержка мы решили не тестировать его. В итоге ProxySQL тоже не прошел по задержкам оставив первенство Haproxy. Если у вас есть информация о том, что сейчас ситуация изменилась и MaxScale может обогнать ProxySQL, то мы с удовольствием протестируем его скорость работы.
Из-за того, что в MySQL репликация асинхронная слейвы могли отставать на неопределенное время. Все критичные данные приходилось читать с мастера.
Из предыдущего пункта вытекает сложность разработки. Разработчик не мог просто сделать запрос к БД, а был обязан продумать готов ли он в каждом конкретном случае к отставанию слейва и если нет, то читать данные с мастера.
Пожалуйста, объясните, как при использовании асинхронной репликации (пусть и с плюшками) устраняются эти проблемы (что надо думать, откуда читаешь), за счет чего? Я с Percona Cluster не работал, но там репликация все равно асинхронная, и в любой момент времени отсутствие отставания, несоответствия читаемых данных (пусть даже на одну транзакцию) ничем не гарантировано. В приложении все равно надо думать о том, откуда именно читаешь, и для чего эти прочитанное будет использоваться — если для модификации — почти всегда надо читать с мастера, ограничение на отставание слейвов тут не сильно поможет, как мне кажется. Я думал что Percona, что Galera кластеры предназначены в первую очередь для защиты от потери транзакций в случае выхода мастера из строя, они не решают задачу масштабирования.
Вы абсолютно правы, репликация все равно асинхронная и думать все равно приходится. Разница в том, что у нас например длина очереди 173 транзакции, это примерно 0.5 сек отставания при больших транзакциях (округлим до секунды). Разработчик может быть уверен, что измененные данные окажутся на слейве через секунду. В случае обычной асинхронной репликации никаких гарантий нет и слейв может отставать например на пол часа. Хотя на корню это проблему конечно не решает, это не настоящая синхронная репликация.
Еще можно использовать переменную «wsrep_sync_wait=7». Это заставит ноду выполнить запрос только после применения всех транзакций в текущей очереди.
Как я уже писал отказоустойчивость это основная причина внедрения кластера у нас. Но защищены только те транзакции, которые успели реплицироваться на остальные ноды. При внезапном падении сервера могут быть потерянные транзакции.
Еще можно использовать переменную «wsrep_sync_wait=7». Это заставит ноду выполнить запрос только после применения всех транзакций в текущей очереди.
Как я уже писал отказоустойчивость это основная причина внедрения кластера у нас. Но защищены только те транзакции, которые успели реплицироваться на остальные ноды. При внезапном падении сервера могут быть потерянные транзакции.
Размер данных вы указали, а какая часть из них горячие? Она влезает в память?
Если «активно применяется кэширование в Redis и Memcache», то почему R всё ещё 96%? Или я неправильно понял?
Так же не совсем понятно с недостатком:
К достоинствам PXC можно отнести комплексную документацию и простой, относительно InnoDB cluster (GR), bootstrap.
По каким причинам в рассмотрение не попал MySQL NDB Cluster?
Если «активно применяется кэширование в Redis и Memcache», то почему R всё ещё 96%? Или я неправильно понял?
Так же не совсем понятно с недостатком:
Из предыдущего пункта вытекает сложность разработки. Разработчик не мог просто сделать запрос к БД, а был обязан продумать готов ли он в каждом конкретном случае к отставанию слейва и если нет, то читать данные с мастера.Если репликация всё равно асинхронная, то в чем принципиальная разница для разработчика разъедутся ноды на 10 или 1000 транзакций?
К достоинствам PXC можно отнести комплексную документацию и простой, относительно InnoDB cluster (GR), bootstrap.
По каким причинам в рассмотрение не попал MySQL NDB Cluster?
Все горячие данные помещаются в память, чтение с диска минимальное, в районе 100-200 IOPS. Да, большие выборки активно кэшируются, на nosql бд приходит около 30к rps. Из MySQL в основном делаются простые выборки по Primary Key для тех данных, которые нежелательно или не нужно кэшировать. Постоянно обновляется кэш и работают кроны, которые используют напрямую БД без кэша.
Честно говоря не помню, почему то исключили его из рассмотрения в самом начале поисков решения.
Если репликация всё равно асинхронная, то в чем принципиальная разница для разработчика разъедутся ноды на 10 или 1000 транзакций?Важно то, что мы знаем на сколько они могут разъехаться, рассчитывать на константу проще. Подробнее ответил в комментарии выше.
По каким причинам в рассмотрение не попал MySQL NDB Cluster?
Честно говоря не помню, почему то исключили его из рассмотрения в самом начале поисков решения.
NDB cluster быстрый, но совершенно ужасный для поддержки в бесплатном режиме. если кластер падает, то быстро его не поднять пока не вольешь всю базу заново. так же он жестко ограничивает обьем размером оперативной памяти нод. а еще он хранит весь лог в памяти что сокращает место для самой базы. в общем отказались от него в пользу перконы в свое время.
а вы задумывались над тем что будете делать когда упретесь в лимиты по записи в кластер? кластер ведь масштабирует только чтение, но не запись. может есть какие то мысли по поводу удобного шардинга в мускл? не ручного
Скорость записи ограничивается двумя параметрами: диском и сетью. С дисками у нас проблем нет, они могут сильно больше, чем у нас есть сейчас (сейчас 400-600 qps, диски могут вытянуть 40-60к). Сейчас ограничивающим фактором является сеть (1 Gbit/s), по ощущениям через нее можно пропихнуть 1.5-2к qps. Сеть планируем апгрейдить.
По масштабированию на уровне кластер — если понадобится вероятно будем шардировать на уровне приложения на несколько кластеров.
По масштабированию на уровне кластер — если понадобится вероятно будем шардировать на уровне приложения на несколько кластеров.
В пользу ProxySQL стоит отметить возможность прозрачного (для web-приложения) разнесения записи/чтения по узлам:
Судя по конфигу, ваше приложение запросы на чтение и запись посылает на разные порты, что позволяет использовать harpoxy.
Судя по конфигу, ваше приложение запросы на чтение и запись посылает на разные порты, что позволяет использовать harpoxy.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Миграция реального приложения со standalone MySQL на Percona XtraDB Cluster