|
|
Задавайте вопросы, мы ответим
Вы не зашли.
Понимаю, вопрос больше касается MSSQL, но всё же, может кто сталкивался. Необходимо на MSSQL сервере выполнить копирование данных в базу MySQL. При этом это не дамп, нужна постоянная репликация данных.
Сам я в MSSQL ноль 
Хотя нет... где-то 0.1 
Попробовал через ODBC, но естественно не получилось, т.к. пытался использовать просто dsn.table (на большее ума не хватило, пардон). Скорее всего, если такое вообще возможно, синтаксис прямого обращения к DSN не такой.
Буду благодарен за любую информацию.
Неактивен
Идея правильная, реализация не очень.
Честную репликацию Вы сделать, конечно, не сможете. Пробовать стоит начать со следующего:
1. Сделать Job, в котором создать два источника данных (MSSQL + MySQL через ODBC).
2. В Job выбирать нужные таблички и копировать данные между источниками.
3. Ну и назначить выполнение раз в сколько-то времени.
Неактивен
Собссна это понятно, что будет какой-то джоб или триггер с необходимыми запросами
Вопрос в том как должно выглядеть обращение к ресурсам мускля и, возможно, что нужно будет единоразово настроить на мсскл сервере
Неактивен
Подцепляете MySQL через ODBC и работает как с обычным источником данных ODBC. Какие проблемы?
Неактивен
paulus написал:
работает как с обычным источником данных ODBC
Собссна тут подробнее плз))) У мсскл онлайн мануал не очень простой, особенно когда не знаешь что ищешь)))
Как в мсскл обращаться к источнику данных? Как я писал, обращение в виде dsn.table вызвало ошибку.
Неактивен
Т.е. нужно идти на форум по MSSQL?
Неактивен
Думаю, да, у меня нет доступа к MSSQL нигде сейчас, чтобы попробовать... 
Неактивен
Пасиба за компанию, будем копать дальше
Неактивен
В mssql существует собственный процесс репликации между ms sql серверами (merge and transactional). Здесь понятно это не подходит. Однако можно взять за основу сам подход, который состоит в том, что реплицируются не все данные, а только изменненные по отношению к ранее сгенерированному снимку. Снимок - это набор файлов, в которых хранится информация о схеме и сами данные в первый момент репликации. то есть это база. Передачу данных и проверку схемы, а так же конфликтов, возникающих при слиянии данных между публикатором и подписчиком выполняет агент репликации replmerg.exe.
Именно в нем и происходит создание коннекта к двум базам данных публикатора и подписчика, анализ, что (insert, update or delete) и в каком направлении выполнять изменения. При одновременном возникновении изменений со стороны подписчика и публикатора одних и тех же данных выполняется процедура разрешения конфликтов.
Вот собственно говоря краткая постановка задачи. Дальше нужно сесть и написать такого агента, у которого с одной стороны mssql, а с другой mysql. Другого правильного пути не вижу, если мы на самом деле говорим о репликации данных в реальном масштабе времени..
Задача интересная и сложная, но логически понятная.
Неактивен
Аналогичная задача. Нужно однонаправленная репликация MSSQL->MySQL ряда таблиц. Структура данных в MSSQL и MySQL разная.
Очень нравится подход предложенный Игорем.
Собственно вопрос - есть кто готовый взяться за реализацию такой задачи?
Неактивен
Это делается подключением MySQL через ODBC и тупым копированием данных
по времени. Думаю, Вы справитесь и сами
Неактивен
Нет, тут вопрос не в том могу ли я справится или нет.
За деньги кто-то готов это для меня проделать?
Неактивен
P.S. Сейчас это у нас работает так: мы подключаемся PHP-приложением к MSSQL и копируем полностью все данные из нужных таблиц в MySQL. Таблицы большие, работает медленно. Нужно, чтобы копировались только изменения в данных, тогда будет работать быстро.
Отредактированно stepanov (19.02.2010 13:28:43)
Неактивен
Собственно, здесь http://www.mysql.com/downloads/connector/odbc/
растет mysql'евский коннектор odbc, ну а mssql'евский вроде и так встроен, в панель управления/администрирование/источники данных можно создать источник данных, ну а дальше через любой odbc клиент и копировать данные. Если не используются какие-либо сильно специфичные mssql'евские типы, то не должно проблем быть.
Правда если говорить про регулярную репликацию (допустим, запускаемую по планировщику), то сходу не приходит в голову какой софтиной можно воспользоваться, но не столь будет трудно написать ее ручками, используя odbc api
http://msdn.microsoft.com/ru-ru/library/s9ds2ktb.aspx
Это если на Visual Studio ориентироваться, в Builder'е и так есть компонент для работы с odbc-источником.
Неактивен
А зачем что-то писать? В MSSQL встроенная копировалка (которая графическая)
отлично справляется со своей задачей; ну и расписание через тот же gui настраи-
вается. PHP там не нужен.
Как утопический вариант — настроить *встроенную* репликацию MSSQL на тот
же (или если не получится — поднять второй пустой instance на том же сервере),
где таблички MySQL подключены как внешние
Неактивен
По вашим ответам я понял, что я очень плохо описал задачу, прошу прощения. Попробуем еще раз.
Cистема выглядит следующим образом:
1) Есть сервер под виндой с MSSQL. Сервер обслуживает большой сайт, который является источником данных для нашего сайта поменьше. Сервер на самом деле не один, их много и они реплицируются, но мы работаем с одни из них.
У нас есть возможность коннектиться к этому MSSQL и работать с view некоторых таблиц. Полного доступа к серверу нет и не будет, но можно договориться, чтобы какие-то операции на нем сделали, если потребуется.
2) Есть наш сервер под линуксом. На нем развернут наш сайт. Там же стоит MySQL.
Как это работает сейчас
Раз в 6 часов наш сервер коннектиться к MSSQL и вытягивает из соответствующих view все данные. На данный момент это около 2 млн строк, но будет раз в 30-40 больше. Он обрабатывает эти данные (потому, что структура данных разная) и запихивает в MySQL. Далее с этими данными, через сайт, уже работают конечные пользователи.
На данный момент операция по переброске данных MSSQL -> MySQL занимает около 4 часов. Это очень медленно.
Суть задачи
Сделать так, чтобы наш сервер не тянул все данные из view, а тянул только изменившиеся с последнего раза. Их будет в разы меньше.
Самый простой вариант - ввести во вью поле modification_date и делать запросы вида
WHERE `modification_date`>"последнего раза"
не прокатывает из-за специфики системы, из которой берутся данные. Они просто не могут ввести триггер, который это поле будет обновлять, из-за большой нагрузки.
Неактивен
Договоритесь, чтобы они с их стороны завели Вам отдельную табличку, в которую
помещались бы триггером строки «журнала изменений». Добавлять туда нужно
только id изменений (и, возможно, тип — INSERT/UPDATE/DELETE). Объединяя
Ваше представление с этой маленькой табличкой, Вы получите список изменившихся
строк. Собственно, всё.
Также Вы можете договориться, чтобы они с их стороны подцепили Вашу linux-машинку
по ODBC и настроили автоматическую репликацию
Неактивен
