- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
1. не умеет без подключенного скрипта, а вы его включите и допишите.
haproxy только и умеет, что определять доступность сервера.
2. вот кусок кода sqlrelay :
да-а-асвиданья, говорить сначала научись.. (c) Филя
3. отставания репликации.
Я думаю, вы просто не знаете еще, что вам нужен обычный "подхват" бекапным сервером на уровне веб
(хотя и с настроенным master-master mysql). Это наименее проблемная традиционная схема.
Ну, не будем мешать.
1. не умеет без подключенного скрипта, а вы его включите и допишите.
haproxy только и умеет, что определять доступность сервера.
1. Ничего подобного в интернете не нашёл :(
2. Она умеет многое, кроме разделения запросов. Можно бэкапные сервера указывать, удобная статистика, проверка хоть чего с помощью скриптов.
Нашёл практически полную инструкцию по моей проблеме, включая проверку работы репликации и полной доступности и нагрузки серверов.
Только вот не знаю, чем или как(?) разделить запросы чтение/запись по разным портам.
1. прямо в поставке mysql-proxy share\doc\mysql-proxy\rw-splitting.lua
2. ну код видели? почти во всех скриптах есть использование mysql_insert_id().
судя по коду, будет всегда возвращать 0.
в mysql-proxy это продумали.
1. прямо в поставке mysql-proxy share\doc\mysql-proxy\rw-splitting.lua
2. ну код видели? почти во всех скриптах есть использование mysql_insert_id().
судя по коду, будет всегда возвращать 0.
в mysql-proxy это продумали.
1. Всё это уже давно читал.
1) Оно умеет только явно указывать сервера для чтения. Не умеет оно менять роли серверов.
2) Если упадёт сервер для записи, то даже чтение работать не будет. Это известная бага.
2. Второй пункт был про haproxy. sqlproxy я только глянул как вариант.
1. 2) пишут что так. похоже, это еще одна причина делать failover на уровне HTTP
1. 2) действительно. значит это еще одна причина делать failover на уровне HTTP
failover я решил делать на уровне haproxy. Очень гибко делается. Можно указать, что делать при падении одного из серверов. Скажем врубить такой-то, вырубить такой-то и т.п.
Вот только что перед ним поставить, чтобы тупо разделять запросы на чтение/запись ...
Иначе придётся скрипты переписывать, чтобы запросы шли на разные порты. Вот это уже затратно 🤣
mysqlproxy
mysqlproxy
Уже обсуждалось выше.
однозначно нужно глубоко покопаться с lua. я сейчас попробовал rw-splitting.lua - так там даже set names не обрабатывается корректно.
однозначно нужно глубоко покопаться с lua. я сейчас попробовал rw-splitting.lua - так там даже set names не обрабатывается корректно.
Вот я и говорю, глюков куча...
Не хочется геморрой ловить.
P.S.: Сейчас тестируем чтение и запись на разных портах с балансировкой. haproxy себя пока очень хорошо показывает.