У нас есть производственный сервер, на котором запущен SQL-Server, на котором хранятся наши внутренние данные, например, информация о клиентах, счета-фактуры и т. Д. Природа этих данных заключается в том, что «старые» данные могут изменяться, например, когда клиент обновляет свой адрес.
В настоящее время мы используем экземпляр Windows Server 2008 в качестве исследовательского сервера, так что у нас может быть запущено подчиненное устройство MS-SQL, которое реплицируется с реального сервера транзакционным способом. Затем мы выполняем ежедневный экспорт плоских файлов из ведомого устройства в нашу схему исследования, которая является базой данных MySQL. Мы делаем это, считывая подчиненные данные в некоторые алгоритмы, которые изменяют и записывают данные в исследовательскую базу данных MySQL. Мы отбрасываем все таблицы в базе данных исследования и выполняем чистый импорт каждый день, чтобы иметь дело со «старыми» данными, которые могли измениться в производственной и подчиненной БД.
Итак, по сути, переход от живой БД к нашей схеме исследования всегда включает в себя полный дамп и повторный импорт каждый день, что для нас нормально, потому что все это делается локально.
К сожалению, у нас много проблем как с репликацией MS-SQL, так и с сервером Windows; источник этих проблем на самом деле в основном человеческий, а не технический. Тем не менее, мы добавили проблемы, связанные с использованием других серверов приложений Linux, потому что запуск некоторых платформ / стеков, которые нам нужны в других областях, сложно в Windows ...
Я хочу переместить наш исследовательский сервер в Linux, с которым я гораздо лучше знаком и способный правильно управлять и настраивать, но я не знаю лучшего плана действий для получения из действующей базы данных MS-SQL к нашей исследовательской схеме MySQL, поскольку теперь у нас не будет возможности иметь репликацию в реальном времени на ведомое устройство.
В принципе:
Наши процессы обновления для добавления данных SQL-сервера в нашу схему исследования предполагают полный импорт каждый день, но, конечно, не имеет значения, импортируются ли они из плоских файлов / файлов SQL или таблиц.
Итак, мы знаем, что так или иначе мы будем выполнять импорт данных SQL-сервера в виде плоских файлов, но вопрос в том, есть ли разумный способ выполнять экспорт из таблиц MS-SQL ежедневно, без необходимости сделать дамп целиком?
я не Говоря о репликации, потому что на принимающей стороне не будет экземпляра MS-SQL, потому что это сервер Linux. Но можно ли, скажем, экспортировать с сервера MS-SQL только строки, поля которых были изменены? То есть, конечно, без изменения схем таблиц SQL-Server для пометки отредактированных строк ... :-)
Может ли SQL-сервер вести журнал измененных строк или что-то еще?
Если все это не удается, есть ли у кого-нибудь подозрения о том, будет ли ожидаться, что экземпляр SQL-Server с недостаточным предоставлением ресурсов будет падать каждый раз, когда вы выполняете экспорт 3 ГБ ???? Тот бит, который я действительно не покупаю ... Мы говорим о минимальной нагрузке на БД в ранние утренние часы (мы - небольшой интернет-магазин B2B, поэтому не ожидаем, что в эти часы что-то будет происходить) .
Спасибо!
Если исследовательский сервер содержит только данные, основанные на производственной БД, почему бы не запустить SQL Server на ваших Linux-серверах вместо MySQL? Если размер вашей производственной базы данных меньше 4 ГБ (похоже, что это так), вы можете запустить выпуск SQL Server Express бесплатно.
Вам не потребуется отдельный шаг экспорта. ИТ-специалисты уже должны делать полные резервные копии и резервные копии журналов транзакций производственной БД, поэтому они уже оплатили затраты на ввод-вывод. SQL Server Express легко сможет читать и восстанавливать из этих резервных копий на ваш сервер Linux.
Я лично никогда не использовал репликацию БД SQL Server, но похоже, что она у вас есть. Таким образом, у вас также будет возможность репликации из рабочей среды в исследовательскую базу данных.
SQL Server 2017 в Linux
А теперь есть SQL Server 2019, который обязательно станет лучше!
Если вы хотите сохранить этот «подчиненный» SQL Server, я бы посоветовал забыть о репликации, просто загружая ежедневную резервную копию на сервер или возиться с резервными копиями журнала транзакций восстановления. Администраторы баз данных должны иметь это под рукой, вам просто нужно убедить их помочь вам получить автоматическое восстановление производственных данных на «подчиненном» устройстве. НО, мне кажется, вы бы предпочли, чтобы рабская коробка ушла.
Я бы подробно рассмотрел функции «Отслеживание изменений» и «Сбор данных об изменениях». Из того, что я прочитал, «Отслеживание изменений» идентифицирует строки, которые были изменены в отслеживаемых таблицах, путем предоставления списка значений первичного ключа. «Сбор данных об изменениях» предоставляет дополнительную информацию, включая регистрацию фактических значений до и после, для полного аудита. Рекламное объявление, нарисованное от руки, заключается в том, что вы читаете из таблиц SQL Server, которые описывают, что изменилось, а затем обновляете свою базу данных mysql. Ни причудливой репликации, ни агентов, ни чего-то еще. Вот MS целевая страница для этих функций.
Мне кажется, вы могли бы просто использовать отслеживание изменений и перезаписать все, что находится в mysql, с текущим хорошим значением из SQL Server. Я ожидал, что система отслеживания измененных данных создаст больше нагрузки, чем отслеживание изменений.
Что касается ежедневного извлечения 3 ГБ: я видел серверы с избыточным выделением ресурсов и плохо работающими хранилищами SAN. Наличие большого количества ядер не решает всех проблем. Ночные периоды часто связаны с другими делами, такими как резервное копирование, дефрагментация, другие извлечения, запуски больших отчетов и т. Д. Для меня «интернет-магазин» означает, что у вас может быть трафик в любое время. Администраторы баз данных могут просто опасаться добавлять ненужную нагрузку.
Я знаю, что вы упомянули, что не хотите изменять таблицы, но думали ли вы о добавлении триггера обновления / вставки в таблицу, чтобы написать файл drop, который ваш Linux-сервер может затем забрать и обновить сервер MySQL?
Что-то вроде
USE [DatabaseName]
GO
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
ALTER TRIGGER [dbo].[trig_WriteDropfileOnChange] ON [dbo].[tableName]
FOR INSERT, UPDATE
AS
-- declare vars
DECLARE @RecordId bigint,
@RetCode int,
@FileSystem int,
@FileHandle int,
@MyDate varchar(255),
@FileName varchar(255)
-- build filename
SET @MyDate = getDate()
SET @MyDate = REPLACE(@MyDate, ':', '')
SET @MyDate = REPLACE(@MyDate, ' ', '')
SET @MyDate = REPLACE(@MyDate, '-', '')
SET @MyDate = REPLACE(@MyDate, '.', '')
SELECT @RecordID = myfield
FROM INSERTED
SET @FileName = '\\path\to\drop\directory\' + @MyDate + '.txt'
EXECUTE @RetCode = sp_OACreate 'Scripting.FileSystemObject', @FileSystem OUTPUT
IF (@@ERROR|@RetCode > 0 Or @FileSystem < 0)
RAISEERROR('could not create FileSystemObject', 16, 1)
EXECUTE @RetCode = sp_OAMethod @FileSystem, 'OpenTextFile', @FileHandle OUTPUT, @FileName, 2, 1
IF (@@ERROR|@RetCode > 0 Or @FileHandle < 0)
RAISEERROR('Could not open file.', 16, 1)
EXECUTE @RetCode = sp_OAMethod @FileHandle, 'WriteLine', NULL, CONVERT(varchar, @RecordId)
IF (@@ERROR|@RetCode > 0 Or @FileHandle < 0)
RAISEERROR('Could not write to file.', 16, 1)
EXECUTE @RetCode = sp_OAMethod @FileHandle, 'Close', NULL
IF (@@ERROR|@RetCode > 0)
RAISEERROR('Could not close file.', 16, 1)
EXEC sp_OADestroy @FileSystem