Как я могу разделить чтение и запись с помощью настройки нескольких баз данных с помощью django и postgresql?

как некоторые из вас знают, Django поддерживает несколько баз данных. Этого можно достичь, написав dbrouter для отправки записей в основную базу данных и всех операций чтения в подчиненную, но, как указано в Документы Django для конфигурации Master/Slave

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

Как я могу учесть задержку репликации и несоответствия запросов из-за времени, необходимого для распространения записи на ведомые устройства? Есть ли какой-нибудь код, который я могу реализовать для этого?


django postgresql database-replication master-slave django-orm
person deadlock    schedule 24.05.2013    source источник
comment
вы хотите отключить запись в определенные базы данных?   -  person karthikr    schedule 24.05.2013
comment
@karthikr Эй, я просто пытаюсь сделать все записи ведущими, а все чтения подчиненными. Делая это, я облегчаю нагрузку, потому что вместо одной базы данных, выполняющей все операции чтения и записи, у меня есть две идентичные базы данных, которые разделяют работу, что позволяет всему работать гладко и эффективно:)   -  person deadlock    schedule 24.05.2013
comment
ой, извини. я неправильно понял ваш вопрос.   -  person karthikr    schedule 24.05.2013
comment
@karthikr не беспокойся :)   -  person deadlock    schedule 24.05.2013

Ответы (2)


arrow_upward
4
arrow_downward

Если вы пишете в MASTER и сразу же читаете из SLAVE, вы всегда рискуете столкнуться с несоответствиями. Вы можете уменьшить риск, но вы никогда не сможете избежать его.

Делайте все возможное для профилирования, настройки и минимизации задержки репликации. Поможет отсрочка запроса на чтение до последнего возможного момента. Но этого нельзя полностью избежать, если вы намерены никогда не читать из MASTER.

Если вы рассчитываете задержку репликации при обычном использовании, вы можете настроить что-то вроде django-multidb-router для чтения из MASTER в течение определенного периода времени после записи. Все еще не на 100% безопасно, но вы можете настроить его на 99,9% безопасно для вашей установки.

person perrygeo    schedule 24.05.2013
comment
Спасибо perrygeo, это именно то, что я искал, по крайней мере, таким образом, у меня есть защита, если пользователь решит быстро проверить недавно опубликованный элемент. Ваша помощь очень ценится! - person deadlock; 28.05.2013

arrow_upward
1
arrow_downward

Обратите внимание, что в MySQL 5.6 они представили режим «полусинхронизации» (http://dev.mysql.com/doc/refman/5.6/en/replication-semisync.html), который гарантирует синхронное ведомое устройство при использовании в простой конфигурации ведущий-ведомый (и только одно ведомое устройство). . Это позволяет избежать этой очень специфической проблемы, но то, что вы получаете в согласованности, вы теряете в некотором дополнительном времени транзакции.

person Steven    schedule 06.08.2014