Репликация данных нескольких таблиц в для двух независимых баз в одну сторону

Question

[Андрей Румм]

Доброго времени суток!
Есть две независимые БД с одинаковой структурой. Требуется пополнять первую БД данными избранных таблиц из второй БД.
По сути требуется реплицировать данные второй БД в первую и все.

На сколько я понимаю, 2 независимые базы требуют master-master репликацию. Но репликация односторонняя. Поэтому в конфигурации первого сервера требуется поставить в игнорирование репликации всех таблиц или БД?
Поправьте меня, если я не прав.

Comments

[KEKSOV]

Уточните пожалуйста:

Есть следующая конфигурация:
1. На сервере А есть таблица т1
2. На сервере В есть таблица т1
3. Обе таблицы одинаковы по структуре
4. Данные из А.т1 должны попадать в В.т1

Теперь вопросы:
1. B.т1 является полной копией А.т1 или данные из А.т1 должны как-то дописываться в В.т1
2. Данные в обеих таблицах могут изменяться одновременно или В.т1 это копия только для чтения?
3. Какая СУБД и ОС?

[Андрей Румм]

Отвечаю: 1. Изначально данных A.T1 нет, а все поступающиее в нее данные отправляются в B.T1, в которой уже есть данные.

2. Да в обоих. Обе БД для одного типа ПО, работающего независимо. Но данные на B должны быть поплняемые данными с сервера А.

3. Mysql 5.1, Ubuntu-server. Оба.

Answer 1

[mgyk]

С репликацие тут можно работать, только если вы точно уверены, что никакие ключи не будут пересекаться, и кроме этого, что вы будете делать если в какой-то момент она встанет, и тогда будет совершенно непонятно какая часть данных откуда.

Делайте лучше скриптом, что-то вроде
1) SELECT * FROM A.T1 into outfile 'backup-XXXX";
2) SELECT * FROM B.T1 into outfile 'update-XXXX';
3) LOAD DATA INFILE 'update-XXXX' into A.T1;

Если нужно online все, то тогда лучше сделать это на уровне приложения, чтобы сразу во все таблички данные дописывало. Там и ошибки будет проще ловить.

Comments

[Андрей Румм]

Так серверы разнесены поэтому этот костыль с выборкой и импортом выглядит как-то не по человечески… И мне на самом деле все равно с какого сервера данные в конечном итоге. Репликация же она на то и репликация. Появились изменения, тут же — хоп, и на другой сервер.

И какие могут быть ошибки? Логи репликации обо всем же расскажут, если что не так, или я что-то не понял в вашей логике.

Answer 2

[subvillion]

Реплицировать таблицы можно, можно в режиме master-master, но изначально данные в таблицах должны быть одинаковые. Либо пустые, либо один дамп. Тк изменения в бд пишутся в бинарный лог мастера после чего воспроизводятся на слейве, в вашем случае существующие данные из В никогда не попадут в А, только новые записи после включения репликации. И наоборот.

Comments

[Андрей Румм]

В реплицируемых таблицах данные одинаковы? Или во всей базе? Возможен ли такой вариант: все данные синхронизируемых таблиц резервируются, потом связываются, и после этого нужные данные импортируются в конечную таблицу. Из которой не задумыватся обратная репликация?

[subvillion]

Данные должны быть идентичны в предмете репликации, если это таблица — то в таблице, если база — то в базе.

Вы не понимаете как происходит репликация, никаких механизмов резервирования не предусмотрено, архитекторно в этом нет необходимости. SQL комманды выполняемые на одном сервере передаются на другой почти в явном виде, если в таблице мастера вы сделаете «update id 101» а на слейве такого id нет (тк базы/таблицы отличаются) — реплика остановится.
Пусть вас не вводит в заблуждение maser-master репликация, в MySQL это перекрестная master-slave.

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

[Андрей Румм]

да но тут ключи и связи в этих таблицах должны сохранятся.