Меню
Что нового?

Обоюдная синхрониизация

Zo

Новичок
Обоюдная синхрониизация

Есть:
1.Хостинг-провайдер (Unix/Linux + MySQL + PHP)
2.И есть сервер Linux c Apache+PHP+MySQL в локальной сети.

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

Необходимо:
обеспечить синхронизацию (в моем понимании это одинаковость содержимого) БД у хостинг-провайдера и в локальной сети!
Допустим, что в течение некоторого времени на сервере хостинг-провайдера ( клиентом или служащим через интернет ) и в локальной сети ( сотрудником компании ) были добавлены некоторые данные. Необходимо, чтобы эта все операции на сервере у хостинг-провайдера отразились в БД локальной сети и наоборот!

Вопрос:
Можно ли это обеспечить синхронизацию средствами MySQL? Какие механизмы использовать?
Методы репликации? Какие storage engine использовать, чтобы и получить синхронизацию и целостность данных?
 
440hz

440hz

php.ru
Re: Обоюдная синхрониизация

Автор оригинала: Zo
Допустим, что в течение некоторого времени на сервере хостинг-провайдера и в локальной сети были добавлены некоторые данные.
Нажмите для раскрытия...
изменения вносятся в обе базы и они различны? тогда, наверное, ручками писать скриптец.
 

Zo

Новичок
440hz
ну да! изменения вносятся в обе базы и они различны! - Тема ведь "Обоюдная синхронищация"
Какого рода скриптец?

svetasmirnova
Спасибо за ссылку, я ее читал! :)
Объясни пожалуйста сам мехнаизм как настроить репликацию так, чтобы получилась синхронищация!
Цитата из статьи:
Репликация в MySQL основывается на том, что все изменения базы данных (обновления, удаления и т.д.) протоколируются в двоичном журнале на сервере, а подчиненный сервер читает сохраненные запросы из двоичного журнала головного сервера и выполняет эти запросы на своей копии данных.

Я вижу только способ: создать 2 пары для обновления, сначала первый из серверов играет роль головного, а затем наоборот, подчиненного ...
Но, изменив на серверах данные получим, к примеру на сервере 1 - порцию данных A, а на сервере 2 - B.
Начинаем репликацию, сервер 1, выполняющий функцию главного сервера, посылает данные А и на сервере 2 получаем в журнальчике B+A.
Затем главным становится сервер 2, который посылает уже B+A, что может вызвать проблемы, т.к. запросы А выполнялись, да и что мы получим: A+B+A.
Или я не прав?

+

в одной из статей http://phpclub.ru/talk/showthread.php?s=&threadid=25230&highlight=%F0%E5%EF%EB%E8%EA%E0%F6%E8%FF
по ссылке от
Necromant
говорят, что
Тут основная проблема - конфликты обновлений, когда в обоих базах одну и ту же запись отредактировали.

Кроме того
некий tony2001
на проблему:

есть две базы данных с идентичной структурой
обе в течении определенного времени изменяются...
хочется после репликации получить третью базу, которая имела бы объединение первых двух...

утверждает:
http://www.geocrawler.com/archives/3/194/2000/6/50/3915369/ - это ответ "нет" от Monty (MySQL team)

Но это было в 2000 году!

Кто прав? Решать вам! Так можно или нет?
 

Апельсин

Оранжевое создание
> Спасибо за ссылку, я ее читал!
плохо читали.

> Или я не прав?
не правы. во-первых без специальной опции обновления выполненные репликацией в логи не записываются. во-вторых slave не выполняет обновлений, которые сделаны сервером с тем-же server-id.

> хочется после репликации получить третью базу, которая имела бы объединение первых двух...

почему объединение, если базы должны быть одинковыми? Или вы имелли ввиду что должна быть 3я копия это базы?
 

Zo

Новичок
Апельсин
>почему объединение, если базы должны быть одинковыми? Или вы имелли ввиду что должна быть 3я копия это базы?
Это вообще не про мой случай, а случай, который рассмотрен в ссылке данной мною выше!

Апельсин
Так что ж! Получается можно это спокойно провернуть, по предложенному мною варианту: создание 2-х пар репликаций 2-х серверов?
 

Апельсин

Оранжевое создание
Zo, смотря что понимается под словом "спокойно". Это возможно, а так как деталей мы не знаем, то ..
 
Войдите или зарегистрируйтесь для ответа.
Сверху