Назад | Перейти на главную страницу

Хранение изменений в нескольких базах данных в единой централизованной базе данных

Настройка: несколько баз данных MySQL в разных местах по одной и той же схеме. Базы данных находятся в разработке.

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

Проблема: как собрать данные из нескольких баз данных, хранить их в одном месте и четко обозначить происхождение каждой строки? Мы обсудили использование централизованной БД, которая отслеживает изменения в производственных БД, с той же схемой и одним дополнительным столбцом для источника. По возможности, мы хотели бы избежать внесения изменений в производственную среду.

Поскольку мы не можем использовать репликацию MySQL (несколько ведущих к одному ведомому устройству не разрешены), каковы другие варианты? Существуют ли какие-либо решения для чего-то подобного или нам нужно что-то кодировать самостоятельно? Лучшее решение - изменить схемы базы данных в производственной среде и добавить столбец для источника?

Идея централизованной базы данных не высечена на камне. Если есть решение, которое решает другие наши проблемы без централизованной БД, мы можем быть гибкими.

Любая помощь очень ценится.

Вам нужно будет написать код где-нибудь по ходу дела. Я считаю, что было бы лучше полагаться на то, что MySQL может делать изначально, а не слишком сильно искажать существующее приложение для адаптации.

Один из вариантов, который я предвижу, - это репликация каждого местоположения обратно на отдельные подчиненные процессы на централизованной машине с использованием отложенной репликации MySQL. Теперь ты, конечно, не сможешь счастливо JOIN данные обратно вместе изначально. Но это позволит вам решить проблему разбивки на страницы в логике приложения, сделав данные достаточно географически близкими для работы с ними, и четко определив происхождение всех данных, в каком подчиненном процессе они присутствуют.

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

Будет интересно прочитать другие предложения.

Сделайте все журналы подчиненных MySQL (не двоичных) в файл. .. и направьте файл в чат irc #feed На сервере запустите ircd .. и слушайте #feed chatroom .. и передайте команды в | mysql -D мастер

Если у вас есть второй, доступный только для чтения, «мастер», который реплицируется первым, ваши запросы ко второму не будут блокировать / блокировать каналы.

(по крайней мере, я видел это в более ранних версиях)

j