Ответ
Это фундаментальный принцип классической master-slave (или primary-replica) архитектуры, используемой в PostgreSQL, MySQL и других СУБД. Он обеспечивает несколько ключевых преимуществ:
-
Гарантия консистентности данных (Data Consistency) Это главная причина. Наличие единственного узла для записи (single source of truth) исключает конфликты и рассогласованность данных, которые могли бы возникнуть при одновременной записи в несколько узлов.
-
Упрощение механизма репликации Механизм прост и надёжен: master-узел записывает все изменения в свой лог транзакций (в PostgreSQL это WAL — Write-Ahead Log). Реплики последовательно читают этот лог и применяют изменения к своим данным. Это гораздо проще, чем координировать двунаправленную или многонаправленную синхронизацию.
-
Оптимизация производительности Нагрузка разделяется: master-узел эффективно обрабатывает операции записи, в то время как многочисленные read-only реплики могут обслуживать ресурсоемкие запросы на чтение (например, аналитические отчеты), не замедляя основной узел.
-
Надежность и простота восстановления При сбое реплики система продолжает работать. При сбое master-узла одна из реплик может быть «повышена» до нового master, и процесс восстановления понятен и предсказуем.
-- Попытка записи на реплике предсказуемо вернёт ошибку
ERROR: cannot execute INSERT in a read-only transactionАльтернатива: Для задач, где необходима распределённая запись, существуют multi-master решения (например, PostgreSQL BDR), но они значительно сложнее в настройке, администрировании и разрешении конфликтов.
Ответ 18+ 🔞
Ну вот смотри, классическая эта схема master-slave, она же primary-replica, на которой пол-интернета стоит — PostgreSQL, MySQL и прочая шобла. И главный её принцип, блядь, такой простой, что даже обидно: писать можно только в одного, а читать — откуда угодно. И знаешь, почему так, а не иначе? Не от большой любви к диктатуре, а потому что иначе — пиздец.
Во-первых, консистентность данных, ёпта. Это святое. Должен быть один-единственный источник правды, single source of truth, как там умные говорят. Представь, если бы все реплики могли писать. Одна бы записала, что у Василия баланс 100 рублей, другая — что 200, а третья вообще, что он должен. И кто из них прав? Начинается бардак, рассогласованность, конфликты — волнение ебать, а терпения ноль. А так — один мастер, он и решает, что почём. Всё чётко, как по нотам.
Во-вторых, репликация до идиотизма простая. Мастер все свои изменения пишет в специальный журнал — в PostgreSQL это WAL, Write-Ahead Log, типа чековая книжка. А реплики — они как подхалимы, подходят, этот журнал читают и у себя такие же изменения делают. Всё по цепочке, без сучка без задорины. А если бы все писали, пришлось бы эти журналы как-то между собой синхронизировать, сводить концы с концами — это ж овердохуища мороки, чистая головная боль.
В-третьих, производительность. Гениальное разделение труда, блядь. Мастер — он как повар на кухне, только готовит (пишет). А реплики — это официанты, разносят готовое (читают). Можно нанять десять официантов (реплик), чтобы они разносили тяжёлые аналитические отчёты по залам, а повар-мастер спокойно на кухне новые блюда (данные) создаёт, его не дергают. Красота!
Ну и надёжность, куда ж без неё. Если какой-то официант (реплика) сдох — похуй, остальные работают. Если повар (мастер) загнулся — выбираем самого шустрого официанта, делаем его новым поваром, и кухня снова в строю. Процедура понятная, отработанная, не надо шаманить с бубном.
-- А если какой-нибудь умник попробует на реплике записать что-то, он получит по шапке:
ERROR: cannot execute INSERT in a read-only transactionА что, разве нельзя по-другому? — спросит дотошный читатель. Можно, конечно. Есть multi-master архитектуры, где все узлы и пишут, и читают. Но это, блядь, высший пилотаж, администрирование уровня "сам от себя охуел". Там сплошные конфликты данных, которые надо как-то разрешать, сложнейшая синхронизация — в общем, мартышлюшка для настоящих мазохистов. Для 99% задач старый добрый мастер-слейв — самое то, что доктор прописал. Просто, надёжно, и не надо выёбываться.