Компания
241,30
рейтинг
25 июня 2012 в 18:25

Разработка → Опыт эксплуатации MySQL Master-Master — как пережить аварию датацентра

Всем привет!

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

Говорить о MySQL Master-Master репликации — в контекстах высокой доступности и производительности — модно, но, к сожалению, многие не понимают ее сути и связанных с технологией серьезных ограничений.
Начнем с того, что в классическом MySQL «настоящей» Master-Master репликации — пока нет :-) Но если постараться, можно все таки просто и быстро настроить эффективную схему выживания при отказе одного датацентра и получить свою долю счастья.



Настройка Master-Master


Известно, что для настройки Master-Master нужно настроить смещение ИДшников и установить для каждого сервера свой уникальный идентификатор:

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

Итог: вы самостоятельно настроили MySQL Master-Master на двух серверах и готовы разбираться дальше.


Синхронность


Нужно четко понять раз и навсегда, что классическая репликация MySQL — асинхронна (в версии 5.6 появилась поддержка ПОЛУ-синхронной репликации; ПОЛУ выделено, т.к. она остается не полностью синхронной до сих пор).
К черту теорию, посмотрим чем нам грозит асинхронность репликации. Данные между БД передаются с произвольной задержкой (от миллисекунд до дней). Для архитектуры Master-Slave со Slave можно приложением просто не читать данные, отставшие на, допустим, 30 секунд. А вот для Master-Master все хуже — у нас нет и не будет (даже в случае ПОЛУ-синхронной репликации) никаких гарантий, что копии БД — синхронны. Т.е. один и тот же запрос может выполняться по-разному на каждой из БД. А одновременное выполнение команд:

UPDATE mytable SET mycol=mycol+1; - на одном сервере

UPDATE mytable SET mycol=mycol*3; - на втором сервере


также приведет к рассинхронизации данных в обеих БД (да простят нас Кодд и Дейт).

Одновременная вставка в обе БД одинакового уникального значения столбца (не автоинкремента!) — приведет к остановке репликации по ошибке. Таких «жутких» примеров можно привести множество.
И хотя иногда советуют решения типа «ON DUPLICATE KEY UPDATE», игнорирование ошибок и пр. и заодно перелопатить приложение — здравый смысл подсказывает, что подобные подходы — скользкие и ненадежные.
Думаю, очевидно, к какому коллапсу и несогласованности это может привести ваше приложение.

Итог: использовать асинхронный Master-Master для одновременной записи в обе БД без знания подводных камней — опасно и ненадежно и применяется в редких кейсах.


Магия кольца


Технически возможно объединить MySQL сервера в кольцо. Однако вышеупомянутые проблемы становятся еще острее — добавляется недетерминизм, связанный с распространением записи по кольцу: можно выполнить обновление одновременно на 1 и 3 узле, а мимоходом раз, и на 2 узле. Что из этого получится на каждой ноде — страшно подумать. А поддерживать такое репликационное хозяйство — «сплошное удовольствие», кошмарный сон системного администратора.


Поддержка синхронной репликации в MySQL


Сейчас, в контексте настоящей синхронной Master-Master репликации (когда целостность данных гарантируется и писать можно одновременно на все ноды кластера) много говорят про Galera. Кто-то скажет, что для этого можно попробовать использовать давно известный MySQL NDB Cluster — но широко известно, что этот «автожир» подходит очень узкому кругу приложений, редко из мира веб.
Мы с интересом следим за Galera — возможно именно на ней в будущем будут строить подлинные Master-Master кластера, а пока посмотрим что полезного можно извлечь из имеющихся хорошо проверенных стабильных инструментов.


Польза от асинхронной MySQL Master-Master репликации


Однако, все не так печально. Как бы не ругали классическую MySQL Master-Slave репликацию за:
  • асинхронность (рассинхронизация данных на нодах, отставания ...)
  • недостаточную надежность (flush_log_at_trx_commit=1, sync_binlog=1, sync_relay_log=1, sync_relay_log_info=1, sync_master_info=1, — иногда не достаточно, и репликация при рестарте сервера отваливается)
  • недостаточная поддержка транзакционности (спасибо патчу Percona Server, в котором эта фича реализована)

эта «рабочая лошадка» используется очень широко и приносит массу пользы и счастья системным администраторам:
  • для создания горячего «почти» актуального бэкапа
  • для кластеризации чтений с MySQL слейвов
  • для вертикального шардинга (фильтруем какие таблицы на какие слейвы переносить)
  • для того, чтобы спокойно бэкапить Slave-сервер с помощью mysqldump, не нагружая боевой сервер БД
  • и др.

В «полезную лошадку» можно достаточно быстро превратить и асинхронную Master-Master репликацию. Обычно данную архитектуру называют Master-Master (Active-Passive):

Идеи просты: пишем в одну БД, вторая используется как горячий бэкап, в который можно при необходимости БЫСТРО НАЧАТЬ ПИСАТЬ ДАННЫЕ! Именно «быстро начать писать данные» и дает этой архитектуре такую полезность и HighAvailability-льность.


Немного покурив...


Немного покурив и подумав, можно увидеть еще одно замечательное применение этой «рабочей лошадки» — способность выдержать аварию в локальном датацентре. Нужно просто держать горячую БД в Master-Master (Active-Passive) в другом датацентре, можно и на другом континенте:

Да, вижу, стрелка в горящий датацентр уже не нужна, но оставим для целостности восприятия картинки :-)
Ну а дальше никто нам не запрещает масштабировать чтения на данной архитектуре, получив локальный относительно датацентра кластер:

Только не забываем включить опцию логирования обновлений на мастере для подчиненных серверов.

Риски


Честно говоря, такая схема репликации работает достаточно надежно и мы ее с успехом применяем на Битрикс24 в облаке Amazon и в решении «Географический веб-кластер». Особенности же ее эксплуатации следующие:
  • Начните эксплуатацию в режиме statement-based репликации. Если в логе MySQL появляются сообщения, что типа данный запрос опасно выполнять в этом режиме, т.к. порядок его выполнения на Slave может быть другим — включите режим репликации «mixed» (это может потребовать увеличения режима изоляции транзакций в InnoDB до Repeatable Read). Не рекомендую включать «row-based».
  • Если вы беспокоитесь о производительности, то скорее всего не будете включать параметры: flush_log_at_trx_commit=1, sync_binlog=1, sync_relay_log=1, sync_relay_log_info=1, sync_master_info=1 (сарказм :-) ). Значит вам придется иногда после аварийных рестартов MySQL поднимать репликацию с последней позиции вручную — покурите с маном команды mysqlbinlog, очень много интересного и полезного можно найти.
  • Постарайтесь пока не поднимите репликацию с одной стороны не переключать обратно балансировщик — иначе может начаться каша с данными (и во второй раз Кодд и Дейт могут уже не простить :-) ).



«А компот?»


Забыли про синхронизацию контента между ДЦ. Тут все в принципе стандартно:
Облачное хранилище для шары файлов — Clodo.ru, Selectel.ru, Amazon S3, Google Storage и другие. Интенсивное использование CDN. Передача статики между ДЦ посредством csync2, rsync и других подобных инструментов. Обычно тут проблем не возникает.

Что почитать по этой теме


Стоит посмотреть на проект linux-ha и, видимо, сделать проще на bash ;-) Очень перспективной выглядит Galera. Будем также надеяться, что в MySQL наконец-то сделают «настоящую» Master-Master репликацию, так востребованную сегодня.
И конечно, совсем забыл — данные все равно могут рассинхронизироваться между Master-Master (Active-Passive). Это бывает из-за краха mysql, внезапной перезагрузки сервера, потери позиции репликации, ошибок в ее коде. Ничего страшного, есть лекарство — посложнее:

и попроще типа этого простого скриптика на bash (не используйте на больших таблицах):
#!/bin/bash

DATABASES=`mysql -u root -p${MYSQL_ROOT_PASSWORD} -h $SHARD_L -B -N -e"SHOW DATABASES" | grep -vE '(^binlogs$)|(^performance_schema$)|(^test.*$)|(^information_schema$)'`

for DB in $DATABASES; do

TABLES=`mysql -u root -p${MYSQL_ROOT_PASSWORD} -h $SHARD_L -B -N -D $DB -e"SHOW TABLES"

    for TABLE in $TABLES; do

        CS_L=`mysql -u root -p${MYSQL_ROOT_PASSWORD} -h $SHARD_L -D $DB -B -N -e"CHECKSUM TABLE $TABLE" | awk '{print $2}'`
        CS_R=`mysql -u root -p${MYSQL_ROOT_PASSWORD} -h $SHARD_R -D $DB -B -N -e"CHECKSUM TABLE $TABLE" | awk '{print $2}'`

        if [ "$CS_L" != "$CS_R" ]; then
            echo "${DB}-${TABLE} : DIFF"

            mysql -u root -p${MYSQL_ROOT_PASSWORD} -h $SHARD_L -D $DB -B -N -e"SELECT * FROM $TABLE" > /var/tmp_data/table_diff_${SHARD_L}.tmp
            mysql -u root -p${MYSQL_ROOT_PASSWORD} -h $SHARD_R -D $DB -B -N -e"SELECT * FROM $TABLE" > /var/tmp_data/table_diff_${SHARD_R}.tmp
            diff -u /var/tmp_data/table_diff_${SHARD_L}.tmp /var/tmp_data/table_diff_${SHARD_R}.tmp
            rm -f /var/tmp_data/table_diff_${SHARD_L}.tmp /var/tmp_data/table_diff_${SHARD_R}.tmp

        else
            echo "${DB}-${TABLE} : OK"
        fi

    done

done


Итоги


На проекте Битрикс24 мы интенсивно используем описанную технологию — и это выручало нас не раз. Последнее падение датацента в амазоне 15 июня сего года прошло незаметно для клиентов — мы автоматически переключились на резервный мастер в другом ДЦ.
В статье мы по полочкам разобрали тему MySQL Master-Master, чтобы в дальнейшем не искать в этой технологии скрытого смысла. Рассмотрели опасные и плохо описанные в сети подводные камни. Выбрали для Master-Master (Active-Passive) простое и практичное применение для обеспечения горячего Master-сервера MySQL в другом датацентре (на другом континенте) и теперь сисдамину можно съездить в отпуск не опасаясь, что на всех нодах репликации данные станут разными (больше не упоминаю имен отцов основателей реляционной теории) или молния ударит в датацентр :-) Всем удачи, хорошего настроения и надежной репликации!
Автор: @AlexSerbul
1С-Битрикс
рейтинг 241,30

Комментарии (70)

  • +5
    Подобная конфигурация (Master-Master + переключение трафика) не только защищает от простоев во время аварий, но и очень помогает при проведении любых работ с базой (установка апдейтов, переконфигурирование и т.п.) — без даунтайма для клиентов.
  • +1
    А как быть, если часть данных не успела синхронизироваться со вторым дата-центром? Понятно, что когда связь восстановится, данные синхронизируются, но что делать с критически важными данными?
    • +3
      Увы, это реалии жизни :-(. При аварийном рестарте mysql также могут потеряться отдельные транзакции, а ext2/3/4 — иногда при резете могут угробить метаданные и не автоматически не восстановиться.
      Если для ваш супермегакритична каждая транзакция, то поможет полусинхронная репликация.
      • +1
        Ну, собственно, так я и думал =)
        • 0
          Но по опыту часто хватает возможностей асинхронной репликации же. Поэтому она так распространена, на ее базе строят графы серверов, активно дорабатывают технологию. Значит полезна :-)
  • +4
    Про MySQL NDB Cluster враки. Мы его в боевых условиях для социальной сети 5 лет назад уже использовали. Конечно, тупо перекинуть таблицы ALTER TABLE `bla` ENGINE=NDB и ожидать чуда не получится (однако с тех пор судя по анонсам проблемы с JOIN и многие другие успешно решили). Но если применить здравый смысл, понимать что у вас сетевой кластер (смотрите коммент под спойлером), хорошо проверить свои запросы — то отличная штука, которая позволяет перемолоть очень большой поток запросов.
    Конечно не каждый запрос можно легко перенести, некоторые вообще не переносятся, но учитывая что NDB это просто движок, то в одной базе могут сосуществовать как InnoDB таблицы, так и NDB таблицы. Они даже неплохо используются одновременно в пределах одного запроса, т.е. в приложениях не нужно специально что-то наворачивать. Всё что нужно, это использовать кластер там где надо (т.е. обращаться к NDB нодам), а где не надо — обращаться к обычному MySQL.

    коммент про сетевой кластер и джоины
    Запрос с десятком сложных джоинов (хватает и 1-2 джоинов, просто на массивные таблицы) по определению не может быстро работать в сетевой среде, ибо temporary таблицы — а значит данные нужно подтянуть с нод. Зато фокус с derived table, т.е. вложенными запросами, отлично сработал и позволил ускорить часть запросов даже по сравнению с InnoDB
    • 0
      Для редких кейсов он безусловно подходит. Ничего не имею против, просто предостерег что это не замена InnoDB, и стоит посмотреть на Галеру.
      • +1
        Насчёт редких кейсов я бы поспорил, он довольно много куда пойдёт. Проблема там скорее в другом — кластер это 5 и более машин, а такие мощности не так уж часто нужны, вот и применяют его редко. Но если проект приличных масштабов, то определённо есть смысл его использовать.
        • 0
          Спасибо за комменты. Вообще я в душе где-то уже начал хоронить NDB кластер если честно, может зря :-)
          • +2
            Очень зря. Даже тогда, лет 5 назад, он нас очень сильно удивил и позволил не заниматься разработкой собственных кеширующих сервисов, как это происходит почти с любой социалкой, которая вырастает в прибыльный проект. Начальное тестирование на живую показало возможности масштабирования во всей красе — было у нас там пару тяжелых мест, которые обычный MySQL (InnoDB, 2 x 4 Quad Core, 16 GB RAM при базе в 5 гигов, основательно отюнингованный под проект) мог обслужить в районе 50-60 rps на конкретной странице (мерили через JMeter и грузили живую систему, поэтому там по статистике SQL обслуживал порядка 3к запросов в секунду). Перенос нескольких критичных мест на NDB (ествественно с переделанными запросами, но логика кода 1 в 1 осталась — поменялся только SQL) за несколько минут дало разогнаться JMeter до 400 rps и росло по мере прогрева кластера.

            Так что если вам приходится иметь дело с большими нагрузками на базу — очень стоит тестировать. И ведь он не только чтение масштабирует, но и запись. Если у вас поток данных входящий больше чем способна записать физическая машина — репликация вообще не поможет. Или read/write может быть таким, что репликация будет работать на пределе своих возможностей и грузить записью все ноды так, что сильно скажется на скорости чтения.

            Я вот лично жалею что мне не приходится работать с NDB Cluster больше — нету таких проектов у меня, где применить. А хочется :)
  • +3
    Давно используем Mysql мастер-мастер. В принципе полет нормальный. Еще хотел бы напомнить о таких небезопасных функциях как например NOW() и RAND(). Советую не использовать их при репликации (это касается и обычной MASTER-SLAVE репликации). Хотя вот тут (http://dev.mysql.com/doc/refman/5.1/en/replication-features-functions.html) пишут, что вроде как они реплицируются корректно, но на практике результат может быть непредсказуем. У нас например репликация залипала на полчаса предположительно из-за этих функций.
    • 0
      row based replication
      • 0
        Я бы посоветовал mixed, в row-based может случиться коллапс с объемом траффика :-)
        • 0
          Я бв не советовал mixed. Так как там до сих пор баги.
  • +1
    А можно подробнее про балансировщик? Используете что-то свое или mysql proxy?
    • +1
      Мы размещены в амазоне и перекидываем трафик между ДЦ веб-сервисом ELB. А в каждом ДЦ машины хотят в свою локальную шарду БД. Поэтому если запахло жареным, чик, трафик переходит в другой ДЦ — проветрилось, возвращается в первый ДЦ. Возможно также эффективно для этого заюзать Elastic IPs, у них время переключения меньше (tcp/ip все таки)
      • 0
        т.е., по сути, у вас нет master-master between regions?
        в каждом регионе запущен свой application?
        • +1
          Идея такая — одна база данных в м-м между датацентрами, но, т.к. Active-Passive, то запись в нее идет ТОЛЬКО из одного датацентра. При переключении трафика запись переключается в другой датацентр. Таким образом мы можем на уровне балансировщиков http-трафика переключать домены между датацентрами.

          Т.к. балансировщик амазона может переключать трафик только между датацентрами региона, мы работаем внутри региона. Но в принципе через DNS или амазоновский Route53 можно поднять конфигурацию между регионами/материками.
          • +1
            а, так вы под датацентрами подразумеваете AZ, а я сразу и не понял.
            а я-то, было, подумал, что вы что-то новое придумали :)
            • 0
              Ничего в принципе нового, просто описал технологию, относительно которой вижу кучу заблуждений и разнотолкований.
      • 0
        Что-то не совсем понятно, что тогда делают те машины, на которые переключается трафик, когда что-то сломалось при стандартном рабочем варианте активного мастера? Т.к. они могут писать только в свою БД, в своем регионе, которая пассивна.
        • 0
          Локальная база становится «активной», когда веб-морды, пишущие в нее, начинают получать трафик. А т.к. одновременно может быть активен только один ДЦ из двух, то следовательно получаем Active-Passive мастер-мастер.
          • 0
            Т.е. один из ДЦ всегда неактивен в вашей схеме, правильно?
            • 0
              В каждом ДЦ — несколько тысяч баз данных. Одновременно трафик идет в оба ДЦ, но соблюдается важное правило — писать в БД только в одном ДЦ. При необходимости можно отлючить один из ДЦ от трафика, а можно вернуть трафик одновременно в 2 ДЦ — главное, чтобы не было одновременно записи из обеих ДЦ в одну БД.
              • 0
                Вот именно уточнение этого вопроса мне не давало покоя, спасибо:)
                • 0
                  :-) Мы просто делим трафик. Домен ru — на первый ДЦ, домены com,de — на второй ДЦ. В случае аварии все домены идут в один ДЦ. Как видите — в любом режиме распределения трафика запись идет только в одну, локальную для ДЦ базу данных.
                  • 0
                    А балансить чем? Я подумывал о ELB, который в VPC, то гда им можно между регионами балансить(хотя не проверял еще), это если говорить только о AWS конечно. Тоже немного напрягает привязка его к региону, помнится были проблемы у всей us-east с сетью не так давно, то тогда и эта схема не такая уж и живая окажется.
                    Либо, свои балансеры в каждом регионе и переключаться руками в зависимости от падений с одной стороны.
                    • 0
                      Мы балансим на ELB, без VPC. Внутри одного региона. Да, 4 часа простоя SLA в год. Редко бывает трясет регион, но редко. У них много сервисов на уровне региона живут, не резервировать же их всех:
                      -s3
                      — autoscaling
                      — IAM
                      — cdn

                      Да, можно балансеры в каждом регионе и м-м между регионами. Но трафик сколько будет стоить такой…
                      • 0
                        Вы читаете мои мысли, честное слово) Спасибо за ответы и отличные описания вашего HA опыта.
  • 0
    Как происходит процесс переключения с одного работающего мастера на другой, как-то принудительно вызывается синк бинлога и перевод ноды из статуса мастер в статус слейв? Сколько времени данные докатываются с активного мастера на пассивный?
    • 0
      Запись в локальную БД в одном датацентре прекращается, т.к. http-трафик направляется через балансировщик амазона (командой АПИ) в другой датацентр на другую локальную БД, связанную м-м с первой.

      Данные не докатываются, они постоянно синхронизируются между БД датацентров. В mysql репликация — непрерывный процесс. Но время задержки конечно может плавать, иногда в районе секунд.
      • 0
        Так вот самое интересное же, как вы определяете, что эти секунды уже прошли и что можно начинать лить в другую ноду? Ведь именно тут можно данные потерять.
        • 0
          В mysql репликации все проходит автоматически, никто секунды не считает. Лить можно в любую ноду, главное — не одновременно.
          • 0
            Хм, а если вы добавили запись, сразу после этого произошла смена мастера и сразу за этим вы делаете апдейт на эту самую запись — ошибки не будет?
            • 0
              Тут такая идея. Переключение записи с одного мастера на другой возникает в 2-х случаях:
              1) Мастер завис, сдохло железо или несколько дисков рейда, обесточился датацентр и т.п. Понимаете, в этом случае какие нить данные да и могут потеряться. Зато клиенты продолжают обслуживаться в другом ДЦ. Да, возможно придется ручками поправить запрос репликации, который не может из потока репликации вставится в БД в другом ДЦ — редко но бывает.

              2) Нужно провести обновление ПО на мастере. Мы сначала переключаем трафик и ждем пару минут. Затем тушим мастер. Теоретически ситуация описанная вами возможна (произошла запись в БД1, затем пока эта запись доходит по каналу репликации произошла конфликтующая запись в БД2 — но такие вещи разруливаются руками, просто поток репликации временно остановится, нужно будет его подредактировать, но конечно клиенты этого не заметят), но на практике не ловили еще. Зато удобно :-)
              • 0
                Вооот, теперь всё понятно, спасибо!
  • +1
    У вас на фотографии явно не русские пожарные.
    • 0
      Это точно :-)
  • +1
    HighAvailability-льность ночью читается совершенно по-другому :)
    • 0
      Да уж, иначе чем днем :-) А в сочетании с лошадками вообще башню сносит :-)
  • 0
    Т.е. вместо master-master делаем master-slave с быстрым fallover :) А сколько громких слов про рабочий master-master было сказано :)
    • 0
      А нет. Это мастер-мастер, т.к. каждый сервер является слейвом для другого :-)
  • +2
    Есть еще Percona XtraDB Cluster — логическое продолжение Galera. Выглядит более перспективно, чем репликация MySQL или MySQL MMM.
    • 0
      Вот хочу ее посмотреть внимательно, мы используем Percona Server, отлично себя ведет.
      • 0
        Если не упираетесь в производиьтельность по записи, то вполне можно переходить.
      • +1
        Анналогично.
        Напишите чего нибудь, если посмотрите раньше меня :)
        • 0
          Обязательно :-)
  • +1
    За Российский data center зачёт :)

    А по теме: спасибо, довольно интересно и актуально для меня.
  • 0
    Даже залогинился чтобы написать коммент.
    1. Хранить в скрипте пароль для root от mysql это глупо (PCI DSS)
    2. linux-ha мёрт — да здравствует pacemaker
    3. Мониторить жизнь сервиса баш скриптом это худшее что можно придумать (опять же pacemaker)
    • 0
      pacemaker это та же запутанная и непрозрачная хрень, стоит посмотреть в документацию и попробовать настроить на продакшене :-)
      • 0
        Кластер на pacemaker/corosync разваливался в продакшене регулярно. Тогда уже лучше MySQL MMM — хоть немного стабильнее.
        • 0
          Сделайте на активной ноде долгий селект/апдейт и переключитесь на другую ноду — разваливания кластера на МММ гарантированно.
          • 0
            Что у вас именно разваливается?
            • 0
              При переключении нод запросы могли висеть очень долго, пока не отвалятся по таймауту. Проблема решалась реконнектом.
              • 0
                Такая проблема присутствует. Но любое существующее решение не решает этой проблемы. Как я и писал выше долгие запросы нужно либо убивать по таймауту при switch over'e либо ждать. + Местами помогает переписанный апликейшен.
      • 0
        Pacemaker это в первую очередь готовый стек для написания своих обвзязок. И конечно, в него нужно въехать. А писать кучу баш скриптов который при флапе сетки, проседания по спю и других не штатных ситуациях сделают вам сплит брейн с разсинхронном не только данных, а и клиентов, это действие на любителя.
        А теперь представьте, что у вас таких машинок не 2, 3, 5,10 а 20, 30, 50.
        • 0
          nagios, 1500 тестов у нас и обработчики событий
  • +3
    Очень классно написа статья. Никакой воды! Всё кратко, ясно и понятно + шутке место нашлось. Мерси.
    • +2
      Спасибо :-)
    • 0
      написа --> написана
  • 0
    А как вы первый мастер востанавливаете после сбоя? Вы просто делаете его слейвом запасного мастера, даёте время пока он синхронизируется и переключаете балансер обратно на первый мастер? А если он скажем не просто остановился и не работал часик-другой, а вообще вся информация на нём испортилась и вам надо полностью всю базу из бэкапа востановить и заодно настроить с какого места бинлог включать… Вы же не пойдёте сейчас на единственный работающий мастер сервер и начнёте делать полный бэкап да ещё и с залочеными таблицами, вы ведь так весь ваш сервис можете на часик отрубить… Наверняка вы используете хотбэкапы?
    • 0
      Конечно. Мы делаем горячий снепшот машин средствами амазона (EBS снэшпот + наш скрипт для создания целостного снепшота рейд10). В случае подобной катастрофы:
      — поднимается машина из снепшота с отставшим мастером
      — мастер автоматически догоняет живой мастер
      — трафик снова переключаестя на ставший актуальным мастер

      Мы пробовали XtrаBackup incremental binary снепшоты, но пользоваться амазоновскими вроде проще. Еще конечно мы постоянно бэкапим мастер на третий сервер, слейв. Там тоже бэкап.
  • 0
    UPDATE mytable SET mycol=mycol+1; - на одном сервере UPDATE mytable SET mycol=mycol*3; - на втором сервере

    >> также приведет к рассинхронизации данных в обеих БД

    Тут наверное стоит упомянуть, что рассинхронизация произойдёт только потому, что мы для нового значения колонки используем не константу, а другую колонку. А то я 5 минут тупил пока дошло почему.
    • +1
      Смотри что происходит.
      1) Изначально допустим в колонке на обеих серверах стоит 1.
      2) На первом сервере прибавляем к колонке 1 и получаем 2.
      3) На втором сервере в это же самое время умножаем колонку на 3 и получаем 3.
      4) По потоку (который только один) репликации с первой на вторую машину приходит команда — прибавить 1. 3+1 = 4.
      5) По потоку (который только один) репликации со второй машины на первую приходит команда — умножить на 3. 2*3 = 6.
      В результате на первом сервере — 6, на втором — 4.
      Отличия в том, что на первом сервере к колонке сначала прибавляют 1, затем умножают на 3. А на втором — сначала умножают на 3, затем прибавляют 1. :-)
      • 0
        Это я понял, я просто считаю, что этому место в статье.
  • 0
    Я может, конечно, чего-то не понимаю, но зачем так извращаться, когда есть Oracle MySQL Cluster?
    • 0
      Так обсуждали вроде выше для чего можно и нельзя применять NDB. Слишком сложно и громоздко же, но для некторых кейсов пишут что неплохо работает :-)
      • 0
        Дык там вроде не только NDB, а абсолютно прозрачно можно поставить за ним n серверов.
  • 0
    поправка насчет того что вы пишите
    недостаточная поддержка транзакционности (спасибо патчу Percona Server, в котором эта фича реализована)

    Эта фича к сожалению не работает, так как нужно. Хотя она все еще остается полезной, но когда я ее проверял на работоспособность обнаружил баг. Который заключается в том что репликация стартует со старой позиции из master.info, а не из той что записана в релей логе. Собственно баг репорт bugs.launchpad.net/bugs/937852
  • 0
    Кто-нибудь подскажет, за 2 года в лучшую сторону что-нибудь изменилось? А то эта надпись красным «море подводных камней» перед глазами маячит и не понятно, стоит ли браться вообще.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Самое читаемое Разработка