Можно ли настроить отфильтрованную репликацию базы данных по схеме «звезда»?

Возможно, стоит взглянуть на mysql-table-sync от maatkit, который позволяет синхронизировать таблицы с необязательным предложением --where.

Для этого подойдет SymmetricDS. Это программное обеспечение для синхронизации/репликации данных с поддержкой Интернета, независимое от базы данных. Он использует веб-технологии и технологии баз данных для репликации таблиц между реляционными базами данных почти в реальном времени. Программное обеспечение было разработано для масштабирования для большого количества баз данных, работы с соединениями с низкой пропускной способностью и выдерживания периодов сбоев в сети.

Мы использовали его для синхронизации более 1000 баз данных розничных магазинов MySQL с корпоративной базой данных Oracle.

Я делал это раньше, и, насколько мне известно, это самый простой способ. Вам следует изучить возможность использования репликации слиянием Microsoft SQL Server и фильтрации строк. Ваша фильтрация строк будет настроена так, чтобы иметь столбец, в котором указано, к какому отдельному месту назначения он должен перейти.

Например, ваши таблицы могут выглядеть так:

ID_столбца | столбец2 | назначения

Данные в столбце могут выглядеть так: 12345 | 'данные' | 'сайт1'

Затем вы должны настроить свою репликацию слияния «подписчик» site1 для фильтрации по столбцу «назначение» и значению «site1».

Эта статья, вероятно, поможет:

Фильтрация опубликованных данных для репликации слиянием Существует также статья о msdn под названием «Повышение производительности репликации слиянием», которая может помочь, а также вам нужно будет изучить основы настройки издателей и подписчиков в репликации слиянием SQL Server.

Удачи!

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

Просто случайный указатель: Oracle lite поддерживает это. Я однажды оценил его для аналогичной задачи, однако ему нужно что-то установить на всех клиентах, что не было вариантом. Примерный обзор архитектуры можно найти здесь

Короткий ответ нет, вы должны изменить дизайн.

Длинный ответ да, но это довольно безумно, и будет очень сложно настроить и управлять.

Одним из способов может быть циклическая репликация основной базы данных между сайтами. Используйте сценарий для репликации, скажем, 30 секунд с сайта, запишите, как далеко он продвинулся, а затем перейдите на следующий сайт. Вы можете посмотреть replicate-do-db и друзей< /a> для ограничения того, что реплицируется.

Другой вариант, который, как я не уверен, сработает, состоит в том, чтобы иметь в главном офисе N серверов mysql, которые реплицируются из каждого из офисов сайта, а затем использовать механизм федеративного хранения, чтобы обеспечить общее представление из основной базы данных в подчиненных серверах на каждом сайте. Подчиненные сайты могут реплицироваться из основной базы данных и получать любые необходимые им изменения.

Похоже, вам нужна помощь специалиста - и я, вероятно, не тот.

Насколько "в реальном времени" должна быть эта репликация? Некоторый процесс ETL (или процессы), возможно, является вариантом. мы используем MS SSIS и Oracle внутри компании; SSIS, кажется, довольно хорош для работы типа ETL (но я не работаю с этим конкретным угольным забоем, поэтому я не могу точно сказать).

Насколько изменчивы данные? Можно ли сказать, что данные в основном операционные/транзакционные? О каких объемах данных вы говорите?

Используется ли центральный мастер также как локальная БД для офиса, в котором он расположен? если это так, вы, возможно, захотите изменить это - сделать так, чтобы головной офис работал так же, как удаленный офис - таким образом вы можете относиться ко всем офисам одинаково; вы часто будете сталкиваться с проблемами/аномалиями, если разные сайты обрабатываются по-разному.

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

У меня нет подробного ответа для вас, но это высокий уровень того, что я бы сделал:

Я бы выбрал из каждой базы данных список изменений, произошедших в прошлом (в разумные сроки), построил операторы вставки и удаления, которые объединили бы все данные в «большой» базе данных, а затем разделил бы меньшие наборы операторов вставки и удаления для каждой конкретной базы данных.

Я бы тогда запустил их.

При этой настройке возможны проблемы слияния, если есть какое-либо совпадение с входящими и исходящими данными.

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