Каковы практические недостатки распределения реплики Mongo 3-node, установленной в трех разных регионах AWS для высокой доступности? Или это плохая идея из-за отставания в репликации?Недостатки высокой доступности MongoDB по регионам AWS
Я сделал это раньше, и это сработало достаточно хорошо.
AWS имеет тенденцию иметь очень хорошую задержку между регионами и чрезвычайно избыточной сетью, поэтому отставание в репликации не является проблемой, но вы можете немного увеличить количество закрытых коллекций для учета региональных проблем (например, Hurricane Sandy в одном регионе и солнечная погода в другом).
Поскольку @Orid сказал, что вы, конечно же, захотите обеспечить CAP, сохранив большинство в по крайней мере одной стороне сетевого раздела, который будет существовать между регионами.
Извините за недостаток знаний заранее, но я немного смущен. Что вы подразумеваете под «одной стороной сетевого раздела, которая будет существовать между регионами». Я думал, что причина расщепления реплики с тремя узлами между регионами будет заключаться в том, что если вся область опускается или становится недоступной, есть как минимум 2 узла, которые все еще могут видеть друг друга, чтобы имели место выборы. Если я поместил большинство в одну область, то я бы не смог разбить мои узлы на 3-области? или я теряюсь в терминологии AWS где-то? – user1891085
@ user1891085 это должно помочь: http://blog.mongodb.org/post/505822180/on-distributed-consistency-part-3-net его старый, но все еще хороший – Sammaye
@ user1891085 извините, не видел вашего редактирования, SO no дольше уведомляет об этом. Технически, если в этих случаях никогда не было разделения между этими регионами (в этом случае центры данных), вы могли бы фактически разместить сервер в каждом регионе, однако любое количество вещей могло бы создать разделение здесь, когда часть сети не может взаимодействовать друг с другом, поскольку такая теория CAP уходит в этом случае, большинство из одной стороны помогает предотвратить сценарий CAP – Sammaye
Вы должны поместить два узла в ваш основной DC, в случае сетевого раздела, например, если у вас все еще есть большинство серверов, соприкасающихся друг с другом. –