Можно ли регулярно экспортировать таблицы MS-SQL в другой формат БД в Linux без полных дампов?
У нас есть рабочий сервер, на котором работает SQL-сервер, на котором хранятся наши внутренние данные, например, информация о клиенте, счета-фактуры и т. Д. Природа этих данных заключается в том, что "старые" данные могут измениться, например, клиент обновляет свой адрес.
В настоящее время мы используем экземпляр Windows Server 2008 в качестве исследовательского сервера, чтобы на нем мог работать подчиненный MS-SQL, который реплицируется с реального сервера транзакционным способом. Затем мы ежедневно выполняем экспорт плоских файлов из ведомого устройства в нашу исследовательскую схему, которая является БД MySQL. Мы делаем это путем чтения подчиненных данных в некоторые алгоритмы, которые модифицируют и записывают данные в базу данных исследований MySQL. Мы отбрасываем все таблицы в исследовательской базе данных и выполняем чистый импорт каждый день, чтобы иметь дело со "старыми" данными, которые могли измениться в производственных и подчиненных БД.
Таким образом, по сути, переход от живой базы данных к нашей исследовательской схеме всегда требует полного дампа и повторного импорта каждый день, что хорошо для нас, потому что все это делается локально.
К сожалению, у нас много проблем как с репликацией MS-SQL, так и с сервером Windows; источник этих проблем на самом деле в основном основанный на людях, а не технический. Однако у нас есть некоторые проблемы, связанные с использованием других серверов приложений Linux, поскольку запуск некоторых платформ / стеков, которые нам нужны в других областях, затруднен для Windows...
Я хочу переместить наш исследовательский сервер в Linux-систему, с которой я гораздо лучше знаком и могу правильно управлять и настраивать, но я не знаю лучшего плана действий для получения данных из живой базы данных MS-SQL к нашей исследовательской схеме MySQL, учитывая, что у нас теперь не будет возможности иметь живую репликацию на ведомое устройство.
В принципе:
- Есть около 5 таблиц SQL-сервера общим объемом ~3 ГБ
- наши ИТ-специалисты беспокоятся о загрузке ввода-вывода на производственном сервере, если мы ежедневно выполняем экспорт по 3 ГБ (в настоящее время мы выполняем репликацию транзакций на подчиненное устройство, а затем выполняем экспорт 3 ГБ с подчиненного устройства).
Наши процессы обновления для передачи данных SQL-Server в нашу исследовательскую схему должны выполнять весь импорт каждый день, но, конечно, не имеет значения, импортируются ли они из плоских файлов / файлов SQL или таблиц.
Итак, мы знаем, так или иначе, мы будем выполнять импорт данных SQL-сервера в виде плоских файлов, но вопрос в том, существует ли разумный способ ежедневно выполнять экспорт из таблиц MS-SQL без необходимости сделать весь дамп?
Я не говорю о репликации, потому что на принимающей стороне не будет экземпляра MS-SQL, поскольку он является сервером Linux. Но можно ли, скажем, экспортировать с сервера MS-SQL только те строки, для которых были изменены поля? То есть, конечно, без изменения схем таблиц SQL-Server, чтобы пометить отредактированные строки...:-)
Может ли SQL-сервер вести журнал измененных строк или чего-то еще?
Если все это не удастся, у кого-нибудь есть предположения о том, будет ли ожидаться, что экземпляр SQL-сервера недостаточного обеспечения будет падать каждый раз, когда вы выполняете экспорт в 3 ГБ???? Этот бит я на самом деле не покупаю... Мы говорим о минимальной нагрузке на БД в ранние утренние часы (мы - небольшой интернет-магазин B2B, поэтому не ожидаем, что в эти часы будет много чего происходить),
Спасибо!
2 ответа
Если исследовательский сервер содержит только данные, основанные на производственной БД, почему бы не запустить 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. Наличие большого количества ядер не решает всех проблем. В течение ночных периодов часто происходят другие вещи, такие как резервное копирование, дефрагментация, другие извлечения, большие отчеты и т. Д. Для меня "интернет-магазин" подразумевает, что у вас может быть трафик в любое время. Администраторы баз данных могут просто опасаться добавлять любую нагрузку, которая не обязательна.
Я знаю, что вы упомянули, что не хотите изменять таблицы, но думали ли вы о добавлении в таблицу триггера обновления / вставки для записи файла отбрасывания, который ваш 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