MySQL репликация 2
От: nen777w  
Дата: 13.08.07 14:12
Оценка:
Наткнулся на такую проблемму.
сервер 1 назовем его Master_1 имеет записи в таблице с первичным ключём который к тому же auto_increment
Записи:
1,g
2,h
3,j
4,d
5,e
6,f
сервер 2 назовем его Master_2 имеем записи в таблице, которые отражены в журнале изменений log-bin
1,g
2,h
3,j
4,a
5,b
6,c
При попытке заставить мастер 1 синхронизироваться с мастером 2 получаем ошибку:

Управляем сервером Master_1

//#устанавливаем мастер сервер 1 и его атрибуты.

change master to master_host='Master_1', master_user='admin', master_password = '1', master_port=3306, master_log_file='HWSNotebook-bin.000002'
, master_log_pos=98;

//# запускаем репликацию

start slave; 

//# проверяем
mysql> show slave status\G;

*************************** 1. row ***************************
             Slave_IO_State: Waiting for master to send event
                Master_Host: Master_2
                Master_User: gtms_admin
                Master_Port: 3309
              Connect_Retry: 60
            Master_Log_File: HWSNotebook-bin.000002
        Read_Master_Log_Pos: 717
             Relay_Log_File: vio_test_mysql-relay-bin.000002
              Relay_Log_Pos: 241
      Relay_Master_Log_File: HWSNotebook-bin.000002
           Slave_IO_Running: Yes
          Slave_SQL_Running: No
            Replicate_Do_DB:
        Replicate_Ignore_DB:
         Replicate_Do_Table:
     Replicate_Ignore_Table:
    Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
                 Last_Errno: 1062
                 Last_Error: Error 'Duplicate entry '4' for key 1' on query. Def
ault database: 'gtmsdb'. Query: 'INSERT INTO `t_report_files` (`id_report_file`,
 `report_file`) VALUES (NULL, 'a')'
               Skip_Counter: 0
        Exec_Master_Log_Pos: 98
            Relay_Log_Space: 860
            Until_Condition: None
             Until_Log_File:
              Until_Log_Pos: 0
         Master_SSL_Allowed: No
         Master_SSL_CA_File:
         Master_SSL_CA_Path:
            Master_SSL_Cert:
          Master_SSL_Cipher:
             Master_SSL_Key:
      Seconds_Behind_Master: NULL
1 row in set (0.00 sec)

ERROR:
No query specified


Получается проблема в дублировании ключей.? Но в запросе NULL ?
Re: MySQL репликация 2
От: fidget Украина  
Дата: 17.08.07 14:24
Оценка:
Здравствуйте, nen777w, Вы писали:

N>Наткнулся на такую проблемму.

N>сервер 1 назовем его Master_1 имеет записи в таблице с первичным ключём который к тому же auto_increment
N>Записи:
N>1,g
N>2,h
N>3,j
N>4,d
N>5,e
N>6,f
N>сервер 2 назовем его Master_2 имеем записи в таблице, которые отражены в журнале изменений log-bin
N>1,g
N>2,h
N>3,j
N>4,a
N>5,b
N>6,c
N>При попытке заставить мастер 1 синхронизироваться с мастером 2 получаем ошибку:

N>Получается проблема в дублировании ключей.? Но в запросе NULL ?


В каком запросе NULL? Если даже у вас автоинкрементное поле, то в log-bin у вас идет конкретное число, которое было присвоено автоинкрементному полю. Соответственно если сервера между собой не синхронизированы и вы независимо добавляли значения, то вполне ожидаемо что у вас вылезла эта ошибка.

Если вы хотите использовать Master<->Master репликацию с автоинкрементным полем, то вам надо смотреть в сторону auto_increment_offset и auto_increment_increment, чтобы на каждом мастере генерировалась своя последовательность.

Почитайте вот здесь статью о том, как это правильно организовывать:
http://www.onlamp.com/pub/a/onlamp/2006/04/20/advanced-mysql-replication.html
Re[2]: MySQL репликация 2
От: nen777w  
Дата: 17.08.07 14:39
Оценка:
N>>Получается проблема в дублировании ключей.? Но в запросе NULL ?

F>В каком запросе NULL? Если даже у вас автоинкрементное поле, то в log-bin у вас идет конкретное число, которое было присвоено автоинкрементному полю. Соответственно если сервера между собой не синхронизированы и вы независимо добавляли значения, то вполне ожидаемо что у вас вылезла эта ошибка.


Угум. Спасибо, не знал что в журналах помимо SQL запросах ещё и сохраняется значение полей которое были присвоены в поля для автогернирации.
Вероятно для того что бы правильно сохранить связи? Гм.. я то думал что они используют более хитрый алгоритм для отслеживания связей.

F>Если вы хотите использовать Master<->Master репликацию с автоинкрементным полем, то вам надо смотреть в сторону auto_increment_offset и auto_increment_increment, чтобы на каждом мастере генерировалась своя последовательность.


Да спасибо. Только что докопался до этого.

F>Почитайте вот здесь статью о том, как это правильно организовывать:

http://www.onlamp.com/pub/a/onlamp/2006/04/20/advanced-mysql-replication.html

Как раз отрыл это. И прочитал. Спасибо!

Вы очень много мне помогаете, жили бы в Одессе поставил бы Вам пиво!
Re[2]: MySQL репликация 2
От: nen777w  
Дата: 17.08.07 15:26
Оценка:
F>В каком запросе NULL?

В журнале.

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

Сори что возвращаюсь к вопросу, а нельзя ли заставить подчинённый сервер не брать значения из журнала мастера а самому сгенерировать их сохранив правильно все связи. Ведь по сути то
1) Сервер знает что в поле для таблицы такой то было подставленно значение допустим 23
2) Он вместо него генерирует допустим 55, и запоминает такую связь 23 = 55
3) Потом всем последующим запросам которые где то как то ссылается на эту таблицу и значение 23 на старом сервер вместо 23 ставит 55

Ведь делов то? Мне не верится что разработчики базы об этом не подумали.
Re[3]: MySQL репликация 2
От: fidget Украина  
Дата: 21.08.07 18:22
Оценка:
Здравствуйте, nen777w, Вы писали:
N>Сори что возвращаюсь к вопросу, а нельзя ли заставить подчинённый сервер не брать значения из журнала мастера а самому сгенерировать их сохранив правильно все связи. Ведь по сути то
N>1) Сервер знает что в поле для таблицы такой то было подставленно значение допустим 23
N>2) Он вместо него генерирует допустим 55, и запоминает такую связь 23 = 55
N>3) Потом всем последующим запросам которые где то как то ссылается на эту таблицу и значение 23 на старом сервер вместо 23 ставит 55

N>Ведь делов то? Мне не верится что разработчики базы об этом не подумали.


Нельзя, если вы посмотрите бинарные логи нам перед каждым event идет SET TIMESTAMP и там где надо SET INSERT_ID именно для того чтобы зачения времени и автоинкремента были одинаковыми на мастере и на слэйве.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.