mysql-proxy

[Corwin]

Добрый день.

Интересно, кто-нибудь работал с данной прогой? Какие отзывы по ней?

[Хостинг HostFood.ru]

Тарифы на хостинг в России, от 12 рублей: https://www.host-food.ru/tariffs/hosting/
Тарифы на виртуальные сервера (VPS/VDS/KVM) в РФ, от 189 руб.: https://www.host-food.ru/tariffs/virtualny-server-vps/
Выделенные сервера, Россия, Москва, от 2000 рублей (HP Proliant G5, Intel Xeon E5430 (2.66GHz, Quad-Core, 12Mb), 8Gb RAM, 2x300Gb SAS HDD, P400i, 512Mb, BBU):
https://www.host-food.ru/tariffs/vydelennyi-server-ds/
Недорогие домены в популярных зонах: https://www.host-food.ru/domains/

[zg]

опишите задачу, решение найдётся.

[Corwin]

Благодаря такому прозрачному проксированию MySQL, прокси-сервер предоставляет несколько интересных возможностей:

1. Реализация механизма failover. Вы можете указать прокси-серверу более чем один сервер MySQL и в случае если прокси-сервер не получит ответ от первого MySQL-сервера в силу его отказа, для подключения будет использован следующий сервер по указанному списку.
2. Балансировка нагрузки. Вы можете добиться того, что прокси-сервер будет распределять запросы к MySQL-серверу по нескольким серверам из заданного списка. При этом вы сами можете управлять тем, как это распределение будет осуществляться.
3. Фильтрация клиентов. Вы можете установить свои собственные условия на работу определённых клиентов, например, запретить работу одних клиентов или организовать подмену одного имени пользователя другим.
4. Корректировка или преобразование запросов. Вы можете взять исходный запрос, который передаётся от клиента к серверу и сделать с ним практически всё что угодно: откорректировать, заменить своим собственным, отбросить, дополнить.
5. Корректировка результатов запроса. Вы можете взять ответ MySQL-севрера на запрос и сделать с ним что угодно: изменить, дополнить.
6. Фильтрация запросов. Вы можете вернуть клиенту результат его запроса минуя обращение к серверу, например если по каким-либо критериям решите, что данный запрос выполнять не нужно.
7. Протоколирование запросов и/или результатов запросов. Поскольку вы имеете полный доступ как к самому запросу, так и к результатам его выполнения, вы можете протоколировать и то и другое, а также подсчитывать время выполнения запросов.
8. На любой стадии работы вы можете вызывать внешние программы и действовать в зависимости от полученного после их работы результата.

Описание красивое Поставил его из портов /usr/ports/database/mysql-proxy
Теперь осталось узнать, где конфиги у него? Нашёл в /usr/local/share/example - примеры настроек. Но чего-то пока мало понятно, чего и куда и самое главное, где указывать другие сервера с MySQL и прочие настройки.

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

Моё представление данного вопроса:
Есть сервер, на котором запущен демон билинга. Он обращается к серверу с базами данных. После установки mysql-proxy на том же сервере, где висит демон билинга, он думает, что СУБД находится на том же сервере где и он - то есть обращается через localhost к базам. На самом деле СУБД находятся на других отдельных серверах. Таким образом происходит балансировка нагрузки на сервера СУБД и осуществляется как проксирование так и кэширование запросов. Тема интересна в плане разгрузки серверов СУБД и таким образом реплицирования данных, когда на обоих серверах данные баз идентичны, к которым обращается демон билинга.

[buryanov]

Как-то у меня сервак стал подуставать, кластер собирать было неначем, решил поставить mysql-proxy, подставил ещё один сервер, залил на него базу из дампа... И тут начались проблемы, с синхронизацией. База была не предназначена к этому, проблемы с индексами. Синхронизация запускалась раз в несколько минут, каждую минуту синхронизация не работала, вылитал с ошибками мускул. И к томуже изза несинхронизации получались разные результаты. В итоге всё переехало на кластер

[LMik]

Как-то у меня сервак стал подуставать, кластер собирать было неначем, решил поставить mysql-proxy, подставил ещё один сервер, залил на него базу из дампа... И тут начались проблемы, с синхронизацией. База была не предназначена к этому, проблемы с индексами. Синхронизация запускалась раз в несколько минут, каждую минуту синхронизация не работала, вылитал с ошибками мускул. И к томуже изза несинхронизации получались разные результаты. В итоге всё переехало на кластер

Ну так ведь репликацию надо было делать а не синхронизацию в несколько минут! Ктож так делает
Под кластер точили запросы?

[buryanov]

Описался, делалась репликация.

Под кластер точили запросы?

нет, система уже стояла в продакшине и весь переезд делался "налету", на хранилище пришлось поставить кучу винтов и контроллер, тк при 2 нодах на 1 хранилище, винты напрягались(изначально был собран райд софтовый 0+1 или 1+0, нипомню точно). В конечном итоге 4 нода стало.

[Corwin]

Ну так что, стоит овчинка выделки или нет?

[zg]

Ну так что, стоит овчинка выделки или нет?

есть разные задачи, есть разные решения. В зависимости от задач используют наиболее оптимальное решение.

[buryanov]

Если у вас есть web сайт, который только читает из мускула или тому подобное, когда не нужна запись в базу, либо запись можно организовать отдельной сесией, и ваша база не справляется - то mysql-proxy, это то, что надо для этого, он ставится безпроблем, а добавление нода - добавление 1 строки в конфиг и заливка дампа. Вы организуете запись в каждую базу по отдельности, и в этом случае вам репликация не нужна будет.
Я небольшей знаток програмирования, поступил так: создал дополнительные таблицы, назвал их current_ и в них пишу все текущие данные и потом, раз в сутки, ночью, перенашу данные из неё в основную таблицу. При таком подходе, основные данные (большие таблици) заливаются из дампа, а таблици current_ делаю дамп и сразу переливаю его на новый сервак и при этом в current_ уже могут писаться данные из запросов. Но данный метод требует модификации кода. В случае поднятия кластера, все ноды пользуются одним файлом и никаких модификаций кода вам не требеутся, и вы также видите кластер как 1 машину.
Как вариант для репликаций можно использовать DRBD, те вы поднимаете зеркало через лан. У меня на работе сейчас програмеры пишут проэкт, но им нужна не loadbalans система, a отказоустойчавая. в ихнем случае заказчик не хочет делать отдельное хранилище. И саму технологию, они пока отрабатуют и тестят.