- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Как снизить ДРР до 4,38% и повысить продажи с помощью VK Рекламы
Для интернет-магазина инженерных систем
Мария Лосева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Предстоит делать HA для mysql. Всего порядка 20-30 серверов, надо что бы гарантированно на одном из них был рабочий инстанс с актуальными данными. Нагрузка небольшая, ресурсов одного сервера хватает с избытком.
Рассматриваю следующие варианты:
1. master + slave репликация силами mysql, управление peacemaker-ом
2. drbd между парой серверов, единовременно запущен только один, управляем так же pacemaker'ом
3. штатный mysql кластер
похвалите-поругайте, склоните к выбору, предложите альтернативу?
alw, непонятно. 20-30 серверов с одними и теми же актуальными данными ?
Область применения-то какая ? В стандартном вебе зачастую такие сложности и неизбежные потери производительности не окупаются.
Это openstack кластер. На нодах крутятся виртуалки. Хочется обеспечить HA управляющему софту, что бы выход из строя одной машины не клал все.
Голосую за первый вариант.
Синхронизировать через drbd не вариант, так как могут крешиться таблицы.
Получать ограничения и трудности mysqlcluster когда без них можно обойтись тоже не нужно.
А можно в двух словах про трудности и ограничения mysql'евой кластеризации?
alw, ну так для управления ведь не нужно дублировать данные в 20-30 копиях ? и данных там мало?
Пожалуй, должен подойти штатный кластер ndb mysql. Он старый, проверенный, документированный, максимально обкатан из всех других решений. 2-3 реплики вполне достаточно.
---------- Добавлено 11.06.2013 в 13:09 ----------
А можно в двух словах про трудности и ограничения mysql'евой кластеризации?
Она НЕ ТАКАЯ.
Совершенно верно, данных мало, 20 копий не надо. Хочется держать одного мастера и пару слейвов, работать только с мастером. Мастер сдох - промоутим слейва и делаем нового слейва на следующем сервере. Сдох слейв - просто делаем слейв на следующем сервере.
---------- Добавлено 11.06.2013 в 13:15 ----------
Другой вопрос что хочется что бы все ноды были равноценными, т.е. не говорить что вот на этих трех я ранаю кластер, а на остальных нет. Хочется идентичный конфиг пейсмекера везде, а он уже сам бы раскидывал что куда..
А можно в двух словах про трудности и ограничения mysql'евой кластеризации?
Можно даже не в двух:
http://dev.mysql.com/doc/refman/5.1/en/mysql-cluster-limitations.html
Некоторые ограничения не абстрактные (особенно из первого пункта), а могут действительно мешать.
Возможно, если таблицы простые и маленькие, то этим можно не заморачиваться.
Я за второй вариант
Только соеденяйие сервера кроссом а не чререз свитч
я за master-master репликацию, с одним активным мастером, переключать активный мастер можно переносом IP адреса между серверами
если поставить percona server, то репликация будет восстанавливаться при падении синхронизации
drbd можно, но это заморочки с переключением
"3. штатный mysql кластер" - тормозной на сложных запросах
А у перконы уже есть синхронный слейвинг