Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 75
Зачем делать master-slave репликацию, если Mysql поддерживает master-master?
У меня Слэйв выполняет роль «тени», идущей за Мастером. К Слейву пользователи даже не имеют доступа, пока не произойдет падение Мастера. Поэтому ему нет смысла тоже выполнять роль мастера.
masta-master это самое плохое, что может быть. Хотя нет — самое плохое это «круговая» репликация с > чем 3 мастерами.
Смотря как исползовать, если писать на все мастера, то нужно правильно готовить код и осознавать, что допустим insert into select from может по размному отработать. В любом случае это не подходит если, у вас какая-то CMS которую придется долго запиливать напильником, чтобы все было корректно.
Я использую master-master только для того чтобы не заморачиваться с переключением slave/master при падении одного сервера. Просто перебрасываю ip между серверами.
Я использую master-master только для того чтобы не заморачиваться с переключением slave/master при падении одного сервера. Просто перебрасываю ip между серверами.
почему master-master плохое решение?
proxmox.com
Зачем, если есть ESXi?
1) KVM и OpenVZ работают значительно быстрее чем гипервизор ESXi
2) простой и понятный веб-интерфейс (у ESXi его нет вовсе)
3) легкое построение кластера и миграция машин между нодами
4) open-source
2) простой и понятный веб-интерфейс (у ESXi его нет вовсе)
3) легкое построение кластера и миграция машин между нодами
4) open-source
2 и 4 несущественны: наш ехать а не шашечки.
А вот на 1 и 3 пункты есть пруфы?
А вот на 1 и 3 пункты есть пруфы?
1. голословное утверждение или есть пруф?
2. у ESXi есть клиент (более чем приятный), а, кроме того, онлайная версия go.vmware.com (в облаке!)
3. никаких проблем у VmWare (правда, кажется, уже за деньги, а не в бесплатном варианте)
4. чем автору (пользователю, а не разрабу) поможет это дело?
2. у ESXi есть клиент (более чем приятный), а, кроме того, онлайная версия go.vmware.com (в облаке!)
3. никаких проблем у VmWare (правда, кажется, уже за деньги, а не в бесплатном варианте)
4. чем автору (пользователю, а не разрабу) поможет это дело?
один вопрос — как вы при таком конфиге(slave-master, односторонний rsync) возвращаете в работу «мастер» после его починки?
Бывшего master'а после починки делают slave, скорее всего. Правда, для этого на изначальном slave надо включить bin-log.
По замыслу это делается вручную так:
1) восстанавливается виртуалка master (или откатываю на предыдущий safe-state или беру просто исходную)
2) актуализирую ее (разворачиваю последний дамп базы, взятый со slave, заливаю последние версии скриптов)
3) включаю master в сеть, slave соответственно отключается от сети, подключаю обратно кабель репликации
slave с master местами никогда не меняю. У них есть ряд специфических настроек, они не вполне взаимозаменяемые. Slave нужен, чтобы временно взять работу на себя, чтобы можно было спокойно восстановить master и вернуть все на круги своя.
Да, это восстановление довольно трудоемое (ну 1-2 часа, максимум занимает), но и виртуалка падает крайне редко (стучу по дереву). На самом деле из моего опыта в двух организациях, такая виртуалка, работающая внутри сети годами не дает никаких сбоев.
1) восстанавливается виртуалка master (или откатываю на предыдущий safe-state или беру просто исходную)
2) актуализирую ее (разворачиваю последний дамп базы, взятый со slave, заливаю последние версии скриптов)
3) включаю master в сеть, slave соответственно отключается от сети, подключаю обратно кабель репликации
slave с master местами никогда не меняю. У них есть ряд специфических настроек, они не вполне взаимозаменяемые. Slave нужен, чтобы временно взять работу на себя, чтобы можно было спокойно восстановить master и вернуть все на круги своя.
Да, это восстановление довольно трудоемое (ну 1-2 часа, максимум занимает), но и виртуалка падает крайне редко (стучу по дереву). На самом деле из моего опыта в двух организациях, такая виртуалка, работающая внутри сети годами не дает никаких сбоев.
о опции read-only на слейве автор не слышал.
Если можно поподробнее. Разве не получится, что если я переведу slave в режим read-only, он перестанет у себя выполнять запросы на изменения, приходящие с master и репликация не будет происходить?
Я же на slave имею 2 пользователя MySQL — под одним идет репликация, под другим работают скрипты портала. И я запрещаю изменения тому пользователю, под которым работают скрипты портала, до того момента, пока не прервется репликация и slave не начнет обслуживать пользователей.
Я же на slave имею 2 пользователя MySQL — под одним идет репликация, под другим работают скрипты портала. И я запрещаю изменения тому пользователю, под которым работают скрипты портала, до того момента, пока не прервется репликация и slave не начнет обслуживать пользователей.
dev.mysql.com/doc/refman/5.1/en/server-system-variables.html#sysvar_read_only
Ставишь в my.cnf
read_only
И апдейты будут накатываться только те что пришли с мастер-сервера по препликации и только от пользователей с Super_priv
Ставишь в my.cnf
read_only
И апдейты будут накатываться только те что пришли с мастер-сервера по препликации и только от пользователей с Super_priv
А у меня вопрос про дубли в уникальных ключах, не совсем понял о чем речь и каким образом такие дубли вообще могут создаться, если поле уникальное?
Думаю там 2 варианта. Или оно как бы уникальное или как бы дубли )
Это происходит если войти в портал на slave, в его базу производится, например, запрос INSERT. Соответственно при этом для вставляемой записи в таблице генерится новый ID. При этом на master запускается другой INSERT. И когда в дальнейшем с master приходит этот запрос уже по каналу репликации, то оказывается, что у slave уже есть запись с таким ID и это приводит к разрыву репликации.
Не в тот пост! Я хотел сюда habrahabr.ru/blogs/robot/133614/, простите
тогда что мешало арендовать один дедик в датацентре
Зачем внутрикорпоративный портал размещать вовне?
Автор пишет, что вся жизнь предприятия зависит от работоспособности этой системы. А вдруг или интернет не проплатят, или сбой у провайдера — и всё, доступа к датацентру нету. Надёжность системы уменьшена.
Я думаю запустив сервер на hetzner ничего страшного не случится… это как хранить деньги в швейцарском банке. А экономия на лицо…
А интернет упадет — дык он обычно падает вместе с локальным=) Непроплатить с тем же успехом можно и свет…
Ага. Только электричество за неуплату отключат не раньше чем чрез месяц (и это при плохом раскладе), и то на мозги накапают так, что не заплатить не возможно. А интернет легко могут рубануть первого числа очередного месяца практически без предупреждения (это от провайдера зависит). И, простите, вместе локальным чем падает обычно интернет?
что будет с надежностью системы при пожаре в офисе?
Я делал это год назад, а убунту 8.04.4 вышла в январе 2010, не такая уже древняя на мой взгляд.
Насчет 100$ фрилансеру… Мне это не кажется хорошим решением. Я больше доверяю специалистам 1С-Битрикс (не сочтите за рекламу). Они делают качественно настроенную виртуалку с LAMP.
Вариант с размещением на внешнем хостинге рассматривал. Но там есть минусы: зависимость от Интернета, сложности с монтированием файлового сервера к виртуалке с порталом и вообще с интеграцией в инфраструктуру локальной сети предприятия. Вариант с размещением серверов внутри показался предпочтительнее. Но я не исключаю, что в следующих проектах попробую вариант с внешним хостингом портала (он, безусловно, имеет и свои плюсы).
Насчет 100$ фрилансеру… Мне это не кажется хорошим решением. Я больше доверяю специалистам 1С-Битрикс (не сочтите за рекламу). Они делают качественно настроенную виртуалку с LAMP.
Вариант с размещением на внешнем хостинге рассматривал. Но там есть минусы: зависимость от Интернета, сложности с монтированием файлового сервера к виртуалке с порталом и вообще с интеграцией в инфраструктуру локальной сети предприятия. Вариант с размещением серверов внутри показался предпочтительнее. Но я не исключаю, что в следующих проектах попробую вариант с внешним хостингом портала (он, безусловно, имеет и свои плюсы).
> Ubuntu Linux 8.04.4
o_O
o_O
>>LAMP на базе Ubuntu Linux
>>8.04.4
>>которая работает в виде виртуальной машины VMWare
>>8.04.4
>>которая работает в виде виртуальной машины VMWare
Признатся, тоже не понял зачем поднималась вирт машина и почему такая древняя убунта)
Пока grammar-nazi не прибежали, «признаться»* — опечатался
Убунта не такая уж древняя, она выпущена 28 января 2010 года, а я собирал эту систему год назад. Сейчас уже, конечно, есть более новые версии.
А виртуалка — удобная вещь. Ее можно легко копировать, запоминать состояния и откатывать в случае проблем. Можно в случае чего запускать на любом компьютере и под разными операционными системами.
А виртуалка — удобная вещь. Ее можно легко копировать, запоминать состояния и откатывать в случае проблем. Можно в случае чего запускать на любом компьютере и под разными операционными системами.
«готовую виртуальную машину 1С-Битрикс» забыли :)
А если сервер упадет в 2 ночи? А если Вас утром после вчерашнего тошнит-с и приехать выдернуть шнур выдавить стекло нет никаких? Что-то не вяжется отказоустойчивость с выдергиванием шнура.
я вообще не понял, зачем городить велосипеды с кабелями :)
Шнуры легко могут переткнуть обученные ответственные сисадмины на местах. Это не проблема.
Сразу хочу сказать, что специалистам, работающим с Heartbeat, DRBD, OCFS2, MySQL Cluster эта статья явно не будет интересна. Но если вы новичок в этом, деньги есть только на пару системников, а надежную систему построить хочется, то…
… то лучше все-таки почитайте про DRBD, Heartbeat и иже с ними, и не городите странности.
полностью поддерживаю. Те же два сервака, на которые так грустно потратился ТС и плюс ноду, для которой хватит и старого железа из загашника, чтобы она без проблем следила за жизнью и смертю серваков. У меня в кач-ве ноды летал ВДС на xen'е с 128мб памяти
С этим я согласен, но просто реалии таковы, что поднимать полноценный кластер с DRBD, Heartbeat уже не укладывалось в бюджет проекта. У меня самого на изучение ушло бы много времени и сил, меня хватило на то, на что хватило. А нанимать админа для создания кластера уже не входило в бюджет ну никак.
Но я все равно пробовал найти людей, умеющих делать кластеры DRBD, Heartbeat на сайтах фриланса. Почему-то все говорили, что опыта такого нет. Даже до обсуждения вознаграждения не доходило.
Но я все равно пробовал найти людей, умеющих делать кластеры DRBD, Heartbeat на сайтах фриланса. Почему-то все говорили, что опыта такого нет. Даже до обсуждения вознаграждения не доходило.
А если пожар?
Безусловно, такой подход не гарантирует физической сохранности носителей информации, а следовательно и данных.
Но подозреваю что автор еще и бэкапит куда-то все это дело, чтобы можно было восстановить в таких случаях. Т.к. вероятность реализации физической угрозы не велика, то я думаю можно позволить себе потратить больше времени на восстановление работоспособности системы, в случае чего.
Но подозреваю что автор еще и бэкапит куда-то все это дело, чтобы можно было восстановить в таких случаях. Т.к. вероятность реализации физической угрозы не велика, то я думаю можно позволить себе потратить больше времени на восстановление работоспособности системы, в случае чего.
я надеюсь, что два сервера хотя бы стоят в разных углах офиса, так как если ворвется недавно уволенный сотрудник с гранатой в руке и побежит в серверную, то надежность системы сильно пострадает.
Эта задача решается так:
1) на каждом сервере настроить keepalived (который будет перевешивать ip и при необходимости перезапускать сервисы)
2) mysql репликацию в режиме master-master (+auto_increment_offset) на обоих серверах (позволит писать на любой сервер).
3) GlusterFS в режиме distributed+replicated для хранения файлов на обоих серверах (отказоустойчивое хранилище).
1) на каждом сервере настроить keepalived (который будет перевешивать ip и при необходимости перезапускать сервисы)
2) mysql репликацию в режиме master-master (+auto_increment_offset) на обоих серверах (позволит писать на любой сервер).
3) GlusterFS в режиме distributed+replicated для хранения файлов на обоих серверах (отказоустойчивое хранилище).
У DRBD есть 1 минус — если разъединить ноды и создать на каждой из них по новому файлу(с разными именами), при восстановлении связи всё ломается и приходится руками разрешать «конфликт». Причем нельзя выбрать вариант, когда останутся оба файла. Да, это можно автоматизировать, но суть остаётся прежней — надо выбрать с какой ноды синхронизироваться, а на какой затирать изменения.
В GlusterFS такого косяка нет.
В GlusterFS такого косяка нет.
Автор, приходилось ли проверять эту схему «в бою»? Т. е. были ли сбои первого сервера?
DRBD & HA и не надо никаких образов, ESXi, третьего интерфейса, ручного переключения.
Это все просто будет работать годами.
Это все просто будет работать годами.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как я делал отказоустойчивый веб-сервис