Вопрос о синхронизации баз данных.

[han]

Вопрос о синхронизации баз данных.

Здравствуйте.

На одном моем сайте в сети есть БД и у меня на компьютере подключенном к интернету есть та же БД.
Пользователи заходят в контрольную панель сайта и оставляют свои заказы, которые заносятся в БД.
Со своей стороны я, на локальной машине и локальной БД, выполняю заказ и ставлю статусы выполнен и провожу другие операции.

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

Зачем нужна такая система - отвечаю, т.к. удаленный сервер может порой зависнуть, а выполнять заказы мне нужно всегда.

Подскажите идею как лучше сделать, а уж я то реализую.
Заранее спасибо

 

[alpine]

han
1) Репликация штатными средствами BD.
2) XML_RPC

-~{}~ 01.12.05 08:17:

У тебя кстати mySQL?

 

[han]

да MySQL + PHP

Сделать лучше экспорт в XML файл всех данных из каждой таблички, или только последние записи?

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

 

[alpine]

han
>> Сделать лучше экспорт в XML файл всех данных из каждой таблички, или только последние записи?
Да пишешь скрипт-клиент и скрипт-сервер и выбираешь записи например по дате.

>> А можно про штатные средства репликации по подробней, ни разу с ними не работал.
RTFM
4.10. Репликация в MySQL

 

[han]

Спасибо, интересная штука про XML_RPC и Репликация в MySQL.

А что вы думаете, если синхронизировать через почту?
Изменение прошло, письмо отправлено, выполнен запрос и т.д.

 

[vovanium]

А какой смысл передавать запросы в XML? Если структуры обеих баз данных известны и более того они одинаковые?
Репликация не факт что будет доступна на хостинге.
Нужно просто сделать скрипты экспорта-импорта.

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

ну а как из полученных данных сформировать INSERT/UPDATE запросы, думаю вопросов не возникнет.

 

[alpine]

vovanium
Как ты думаешь сколько уйдет времени на реализацию того что ты написал?

-~{}~ 01.12.05 22:33:

Немного уточню. Будешь ли ты использовать какие-то готовые решения для реализации или ты будешь писать все с нуля? Если да то какие?

 

[vovanium]

Для реализации всего этого времени уйдет меньше, чем на поиск готового решения и прикручивание его
А что я там такого сложно написал?

А в чем проблема то? Данные передать между серваками с помощью fopen или curl или implode/explode сделать с данными? Ты так грозно написал "писать с нуля", да там писать пару десятков строк кода.

Я писал похожую фичу с нуля, так что никаких проблем (тем более, что данные были конфиденциальные, поэтому данные сначала доставались, потом сжимались bzip2 и шифровались AES, после чего передавались по HTTPS), нет ничего сложного если более-менее с php дружишь.

 

[alpine]

1) XML_RPC - это стандартизированный протокол по которому могут обмениваются клиент и сервер между собой информацией и я не вижу смысла придумывать что-то свое.
2) Есть пакет PEAR::XML_RPC используя его API можно в течении 3-4 часов(если в первое +2 часа на раздупляж) написать скрипт-клиента и скрипт-сервера даже без знания самого протокола.
3) Никто никого не заставляет оборочивать в xml все данные. Ты можешь сжатые зашифрованные данные впихнуть в один контейнер.
4) Ты не рассказал как ты будешь синхронизировать при своей модели(TIMESTAMP) DELETE из БД.

 

[vovanium]

1) HTTP тоже стандартизированный протокол, поэтому не вижу никакого смысла использовать всякие надстройки.
2) Допустим. Я одного не могу понять, какие преимущества дает использование XML_RPC. Кроме увеличения кода за счет подключения сторонних компонентов, и увеличения количества передаваемых данных за счет добавления xml'ных тегов?
3) Могу, но зачем? Почему просто не использовать HTTP напрямую? Для того чтобы потом гордиться, тем что ты XML_RPC используешь где нужно и не нужно?
4) Это уже детали. Вообще в случае с заказами, имхо, delete вообще не стоит юзать, должен быть только статус Удаленный, чтобы в случае чего можно было всю историю просмотреть. Но если нужно всё это без проблем решается, просто при удалении web-интерфейсом сохранять удаленные id.

 

[alpine]

vovanium
1) У него "немного" другое назнаяение imho.
2) Я ответил и ответ это скорость разработки, тестироваия и развертывания клиент-серверного приложения.
3) Читай пункт 2.

 

[-=KPOT=-]

делал что то аналогичное
про PEAR::XML_RPC ниче не скажу т.к. не работал

нужна была синхронизация бд раз в сутки причем система была 1 сервак и много терминалов

делал так же как и советовал vovanium
отбирал по TIMESTAMP новые записи
тока помимо записей передавались:
a - список таблиц и их структуры (для возможности отслеживания добавления удаления таблици в бд, но изменения в таблице (добавление/удаленние столбца) не отслеживались)
b - список primary key (как раз для того чтобы узнать че удалено и тб)
с - сами обновленные данные

и все на мой взгляд достаточно просто и написание скрипта не сложное

 

[alpine]

Честно говоря этот топик уже имеет малое отношение к mySQL.

 

[vovanium]

alpine

1) У него "немного" другое назнаяение imho.

Какое у него другое назначение? Если сам XML_RPC использует HTTP, просто добавив немного xml тегов к тому что ты пересылаешь

2) Я ответил и ответ это скорость разработки, тестироваия и развертывания клиент-серверного приложения.

Очень сомнительно, что скорость разработки увеличится. Ну да ладно, пусть автор решает что ему удобнее и проще

 

[alpine]

vovanium
>> Какое у него другое назначение?
HTTP - для взаимодействия вебсервера с приложением (например браузером или удаленным php скриптом), а XML-RPC для взаимодействия приложения которое работает на вебсервере с удаленным пролижением. imho
>> Если сам XML_RPC использует HTTP, просто добавив немного xml тегов к тому что ты пересылаешь
Верно. HTTP - транспортный протокол.