LINUX.ORG.RU
решено ФорумAdmin

Посоветуйте как грамтоней сделать failover сайта.

 , , , ,


1

3

Допустим, хочу сделать сайт на медиавики (php + mysql), расположенный в интранете, отказоустойчивым.
Перечитал гору материала и встречаются кардинально противоположные точки зрения, типа «master-master репликация - это лучшее решение» или «master-master точно угробит БД». Яндекс вон вообще свою базу заббикс на drbd держал, другие пишут, что drbd ломается часто. Как синхронизировать сами сайты, например насколько плохое решение использовать rsync ? Nginx или HAproxy ? Хотелось бы понять какой путь является наиболее отказоустойчивым и автоматизируемым, так сказать best practice.

Deleted

Ответ на: комментарий от beastie

Ну хорошо, допустим в деталях. Действительно ли master-master опасен для данных или это заявление не актуально для новых версий мускуля/марии/перконы ?
Допустим, у меня master-slave синхронная репликация, если мастер помер не синхронизировавшись со слэйвом, что произойдёт с БД, после возвращения мастера в строй ?

Deleted ()
Ответ на: комментарий от Deleted

Сударь, вы упорот? MS-репликация представляет из себя тупое прокатывание бинлога. На каком месте мастер поднимется - с того и продолжит.

svr4 ()

1. drbd говно. 2. Галера говно. 3. Статику синхронизировать подойдет что-то типа ceph. 4. nginx кроме собственно раскидывания нагрузки умеет дохера еще чего полезного (например, кормить клиента заранее гзипованной статикой, делать тамбнейлы из картинок и все такое).

svr4 ()
Ответ на: комментарий от svr4

ceph не будет дичайшим оверхедом для обычного сайтика ?

Deleted ()
Ответ на: комментарий от svr4

Т.е. если изменения пришли в слейв, то разницу надо как-то руками выдирать или что с этим делать потом ?

Deleted ()
Ответ на: комментарий от Deleted

В master/slave по определению изменения пишутся на мастер.

Учитывая, что базы в вебе преимущественно работают на чтение - именно в этом и есть разница между маковыми булками и развитым социализьмом. Много слейвов для readonly и 1-2 мастера для записи.

И да, даже в master-master конфигурации писать одновременно в две базы крайне не советуется - можно смачно половить дедлоков.

svr4 ()
Ответ на: комментарий от svr4

Спасибо.
Т.е. в случае только с двумя серверами master и slave, делать slave основным на время недоступности мастера - очень плохая идея ?

Deleted ()
Ответ на: комментарий от Deleted

В случае MS ты вообще не сможешь переписать изменения, поскольку слейв читает бинлог с мастера, а не наоборот.

svr4 ()

Почти все известные технологии HA хранения данных будут вполне адекватно работать. От remus'а до какого-нибудь master-master mysql. Нода упадёт, юзеры не заметят. Но здесь зарыта лягушка.

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

Наиболее адекватно подъём упавших нод отрабатывает галера на трёх машинах. И то есть проблемы.

По большому счёту, все имеющиеся HA решения предполагают следующую логику работы:

1. Всё работает

2. Одна тачка внезапно сдохла, всё продолжает работать.

3. В удобное для _нас_ время останавливаем сервис, поднимаем починеную ноду.

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

Stanson ★★★★★ ()
Ответ на: комментарий от Stanson

Почти все известные технологии HA хранения данных будут вполне адекватно работать.

А тут пишут, что нет.

Вероятные поломки делают Master-Master репликацию непривлекательной. Выход из строя одного из серверов практически всегда приводит к потере каких-то данных. Последующее восстановление также сильно затрудняется необходимостью ручного анализа данных, которые успели либо не успели скопироваться.

Deleted ()
Ответ на: комментарий от Deleted

master-master MySQL - вообще сложно назвать HA технологией. Это вообще какой-то побочный продукт каких-то мутных экспериментов с репликацией. :) И, как я уже говорил, даже в этом случае, основные проблемы начнутся вовсе не при сдыхании ноды, а при её восстановлении.

Для MySQL лучше пользовать галеру. Правда, понадобится 3 машины, а не 2.

Stanson ★★★★★ ()
Ответ на: комментарий от Deleted

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

redixin ★★★★ ()
Ответ на: комментарий от Deleted

Где можно почитать про тонкости использования галеры ?

загугли MariaDB Galera. Уже достаточно много инфы.

Почему потребуется 3 машины ?

Для проведения голосований без участия человеков при восстановлении одной из нод, так сказать. :) Впрочем, если сдохнут сразу две ноды, то могут быть проблемы, однако, такое развитие событий менее вероятно.

Stanson ★★★★★ ()
Ответ на: комментарий от Stanson

загугли MariaDB Galera

Инет кишит противоречивой инфой, поэтому спросил что можно почитать, кроме официальной документации. Из документации не всегда вытекают тонкости использования.

Deleted ()
Ответ на: комментарий от redixin

Нужно просто почитать как разработчики медиавики рекомендуют деплоить их поделку.

Честно говоря, не осилил загуглить что разработчики рекомендуют.

Deleted ()
Ответ на: комментарий от Deleted

Инет кишит противоречивой инфой, поэтому спросил что можно почитать, кроме официальной документации. Из документации не всегда вытекают тонкости использования.

Насчёт тонкостей - «there is only one way to find out». :) Тонкости очень сильно зависят от твоего юзкейса. Готовой хаутушки про всё в этой области просто не существует из-за весьма ограниченного круга пользователей.

Так что читай всю инфу, поднимай галеру, а там, по ходу дела уже разберёшься.

Stanson ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.