Синхронизация данных таблицы через базы данных

У меня есть одна таблица, которая записывает временные метки вставки/обновления строки в поле.

Я хочу синхронизировать данные в этой таблице с другой таблицей на другом сервере db. Два сервера db не подключены, и синхронизация является одним из способов (ведущий/ведомый). Использование триггеров таблицы не подходит

Мой рабочий процесс:

Я использую глобальный параметр last_sync_date и таблицу запросов Master for измененные/вставленные записи
Вывести результирующие строки в xml
Разберите таблицу xml и update Ведомое устройство, использующее обновления и вставки

Сложность проблемы возникает при работе с удаленными записями главной таблицы. Чтобы поймать удаленные записи, я думаю, что мне нужно вести таблицу журналов для ранее вставленных записей и использовать sql "NOT IN". Это становится проблемой производительности при работе с большими наборами данных.

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

Ответ 1

Похоже, вам нужна очередь транзакций.

Как это работает, просто. Когда вы обновляете master db, вы можете отправить сообщение в брокер сообщений (независимо от того, какое обновление было), которое может перейти в любое количество очередей. Каждый ведомый db может иметь свою собственную очередь и потому, что порядок сохранения очереди должен в конечном счете синхронизироваться (по иронии судьбы, это то, как большинство RDBMS делают репликацию внутри).

Подумайте о очереди сообщений как своего рода базы данных списка изменений SCM или списка патчей.. Это по большей части те же (или примерно одинаковые) операторы SQL, отправленные мастеру, должны быть в конечном итоге, реплицируются в другие базы данных. Не беспокойтесь о потере сообщений, поскольку большинство очередей сообщений поддерживают долговечность и транзакции.

Я рекомендую вам посмотреть spring-amqp и/или spring-integration, особенно если вы отметили это вопрос с spring-batch.

Основываясь на ваших комментариях:

См. Spring Интеграция: http://static.springsource.org/spring-integration/reference/htmlsingle/.
Google SEDA. Если вы идете по этому маршруту или нет, вы должны знать о очередях сообщений, поскольку он идет рука об руку с пакетной обработкой.
В RabbitMQ есть хорошая диаграмма, показывающая, как работает обмен сообщениями
Содержимое вашего сообщения может быть всей строкой, а также ее CRUD, UPDATE, DELETE. Вы можете использовать любой формат (например, JSON. См. Интеграцию Spring по рекомендациям).
- Вы даже можете отправить прямые инструкции SQL в виде сообщения!

Кстати, ваша проблема NOT IN быть проблемой производительности не очень хорошая, так как существует множество рабочих ситуаций, но если вы не хотите делать конкретные вещи DB (например, триггеры и репликацию), я все еще чувствую сообщение очередь - ваш лучший вариант.

EDIT - маршрут без MQ

Поскольку я дал вам трудное время просить этот quesiton, я буду продолжать пытаться помочь. Помимо очереди сообщений вы можете сделать какой-то XML файл, как вы, которого мы пытались раньше. КРИТИЧЕСКАЯ ФУНКЦИЯ, которая вам нужна в схеме, - это столбец CREATE TIMESTAMP в вашей основной базе данных, чтобы вы могли выполнять пакетную обработку во время работы системы (в противном случае вам придется остановить систему). Теперь, если вы пройдете этот маршрут, вы захотите SELECT * WHERE CREATE_TIME < ? меньше текущего времени. В основном, вы только получаете строки в моментальном снимке.

Теперь в вашей другой базе данных для удаления вы собираетесь удалить строки inner joining в таблице идентификаторов, но с помощью != (то есть вы можете использовать JOINS вместо медленного NOT IN). К счастью вам нужен всего ids для удаления, а не для других столбцов. В других столбцах вы можете использовать дельта на основе столбца штампа времени обновления (для обновления и создания aka insert).

Ответ 2

Я не уверен в решении. Но я надеюсь, что эти ссылки могут вам помочь.

http://knowledgebase.apexsql.com/2007/09/how-to-synchronize-data-between.htm

http://www.codeproject.com/Tips/348386/Copy-Synchronize-Table-Data-between-databases

Ответ 3

Почему бы вам просто не добавить столбец TIMESTAMP, который указывает на последнее время обновления/вставки/удаления? Затем добавьте удаленный столбец - т.е. отметьте строку как удаленную, а не удаляйте ее немедленно. Удалите его после экспорта действия удаления.

Если вы не можете изменить использование схемы в существующем приложении:

Не можете ли вы использовать триггеры? Как насчет второй ( "скрытой" ) таблицы, которая заполняется каждым вставкой/обновлением/удалением и которая будет составлять содержимое следующего сгенерированного файла экспорта xml? Это общая концепция: таблица истории (или журнала): у нее будет свой собственный прогрессивный столбец id, который может использоваться как маркер экспорта.

Ответ 4

Посмотрите Oracle GoldenGate:

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

SymmetricDS:

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

Репликатор нарциссов:

Daffodil Replicator - это инструмент Java для синхронизации данных, данных миграции и резервного копирования данных между различными серверами баз данных.

Ответ 5

Очень интересный вопрос.

В этом случае у меня было достаточно ОЗУ для загрузки всех идентификаторов из главных и подчиненных таблиц, чтобы их разделить.

Если идентификаторы в главной таблице последовательны, вы можете поддерживать набор полных заполненных диапазонов в главной таблице (диапазоны со всеми используемыми идентификаторами, без пробелов, например 100, 101, 102, 103).

Чтобы найти удаленные идентификаторы, не загружая их все в память, вы можете выполнить SQL-запрос для подсчета количества записей с id >= full_region.start and id <= full_region.end для каждой заполненной области. Если результат запроса == (full_region.end - full_region.end) + 1 означает, что вся запись в регионе удалена не. В противном случае - разделить область на 2 части и выполнить одну и ту же проверку для обоих из них (во многих случаях только одна сторона содержит удаленные записи).

После некоторой длины диапазона (около 5000, я думаю), он будет быстрее загружать все текущие идентификаторы и проверять, нет ли с помощью Set.

Также есть смысл загружать все идентификаторы в память для партии небольших (10-20 записей) областей.

Ответ 6

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

Напишите пакетное задание Spring для синхронизации данных с ведомым устройством на основе дополнительных полей таблицы истории

надеюсь, что это поможет.

Ответ 7

Потенциальная опция для разрешения удаления в текущем рабочем процессе:

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

Эти идентификаторы должны быть вставлены триггером на вашей основной таблице при удалении.

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

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

Ответ 8

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

Это возможно с MySQL и должно быть возможно с PostgreSQL.

Ответ 9

Я согласен с другим комментарием - для этого требуется использование триггеров. Я думаю, что еще одна таблица должна содержать историю ваших SQL-запросов. См. этот ответ об использовании расширенных событий 2008 года... Затем вы можете получить весь sql и сохранить запрос результата в таблице истории. Это зависит от вас, если вы хотите сохранить его как запрос mysql или запрос mssql.

Ответ 10

Вот мой прием. Вам действительно нужно иметь дело с этим? Я предполагаю, что подчиненный предназначен для целей отчетности. Итак, вопрос, который я задал бы, - насколько это актуально? Это нормально, если данные одного дня? Планируете ли вы ночное обновление?

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