Почему все говорят мне, что мастер-мастер всегда кончается слезами и этого следует избегать?
Потому что нет двух людей, использующих этот термин совершенно одинаково, нет двух людей, настраивающих серверы одинаково, никто не автоматизирует отработку отказа одинаково, и очень немногие люди обладают мастерством mysql, чтобы осуществить это способом, который действительно помогает среде, а не просто добавление сложности.
Это закончится слезами, но если вы все сделаете правильно, они ваш слезы не слезы ваших работодателей или клиентов. И в конце концов, разве не для этого нужны системные администраторы?
Вот некоторые из лучших материалов, которые вы можете прочесть об этом: http://www.mysqlperformanceblog.com/2009/10/09/finding-your-mysql-high-availability-solution-the-definitions/
http://www.mysqlperformanceblog.com/2009/10/16/finding-your-mysql-high-availability-solution-–-the-questions/
http://www.mysqlperformanceblog.com/2009/11/13/finding-your-mysql-high-availability-solution-–-replication/
Посмотрите, что автор High Performance MySQL (2ed) и инструменты Maatkit говорят по этому поводу: http://www.xaprb.com/blog/2008/08/06/how-to-scale-writes-with-master-master-replication-in-mysql/
Ура
Неизбежно оба будут обновляться противоречивым образом между обновлениями, и весь ад вырвется наружу ... Или, по крайней мере, вы получите непредсказуемое поведение.
Представьте себе случай, когда два человека обновляют одну и ту же запись по-разному. Какой из них правильный? В среде Мастер <-> Мастер нет права. Обе записи одинаково верны. Таким образом, он будет проходить и применять их последовательно, вызывая несогласованность данных.
Если вы используете mysql, вы также можете столкнуться с проблемами из-за блокировки на уровне строк ... Эти строки часто не реплицируются. И вам нужно сделать уродливый хакер, чтобы обойти проблему дублирования полей автонумерации (server1 автоматически увеличивает нечетные 1,3,5 и server2 автоматически увеличивает даже 2,4,6).
Это просто некрасиво.
Потому что это всегда заканчивается слезами, и этого следует избегать.
Точнее говоря, репликация MySQL хрупка, и выполнение ее дважды подряд имеет своего рода экспоненциальный эффект на фактор сбоя. Кроме того, внезапно исчезает куча предположений, которые разработчики делают о том, что вы можете и что не можете делать в своей базе данных (например, автоматическое приращение, уникальные индексы и т. Д.), И хотя теоретически вы можете обучить разработчиков этим плохим предположениям, на практике у вас больше шансов попасть на Луну.
Да, и обходные пути к проблемам с многоуровневой репликацией (например, пропуск автоинкремента) означают, что масштабирование путем добавления другого сервера БД - адский процесс.
Отчасти проблема в том, что практически никогда не бывает причин иметь среду мастер-мастер. Правильный способ сделать что-то - использовать слои кеширования и выполнять пакетную запись в базу данных.