|
Задавайте вопросы, мы ответим
Вы не зашли.
Здравствуйте
Имею совсем простую схему: мастер - слейв, но довольно большие базы в среднем по 20Gb, в базах таблицы как myisam так и innodb, перенес дамп, запустил репликацию. С виду все хорошо и правильно, ошибок насчет репликации никаких нет вообще, при просмотре через show slave status позиция мастера растет, ошибок, также никаких. Смотрю relaybinlog через mysqlbinlog на слейве, также вижу все запросы идущие в мастер. ТЕперь внимание вопрос и моя проблема:
запросы не выполняются на слейве, соответстенно и данные в базах быстренько расходятся, слейв стоит, а в мастер пишется.
т.е. все вроде хорошо, нет ошибок, растет позиция мастера на слейве, отставание 0, причем когда стартую слейв (slave start), он очень быстро доходит по позиции до состояния мастера.
Немного сбивчиво и странно получилось, но именно такая ситуация
Народ подскажите, уже незнаю как это побороть, довольно долго смотрел так и не понял, версии сервера мастера и слейва 5.1.х
Неактивен
А полный вывод SHOW SLAVE STATUS\G приведите, пожалуйста?
Неактивен
Спасибо, что так оперативно отреагировали, проблему удалось решить, оказалось, что я забыл пренести хранимые процедуры
Всем спасибо
Неактивен
У меня точно такая же проблема - судя по SHOW MASTER/SLAVE STATUS все в порядке, в логах ошибок нет, в бин-логе слейва есть все запросы сервера, но данные не реплицируются. Помогите пожалуйста решить проблему.
Ниже вывод SHOW SLAVE STATUS:
Отредактированно Eskender (16.09.2011 14:53:12)
Неактивен
Replicate_Do_DB: my_db
В этой базе не реплицируются данные или в другой?
Неактивен
в этой
Неактивен
А текущее соединение на мастере при этом в этой базе или в другой?
Т.е. есть ли запросы вида INSERT INTO my_db.tablename VALUES ( ... )?
Критично ли это ограничение на базу, или можно реплицировать все базы?
Неактивен
Не совсем понял вопрос насчет соединения на мастере, но запросы вида INSERT INTO my_db.tablename VALUES ( ... ) в эту базу на мастере обычно постоянно есть, но пока приостановил запись, чтобы не было рассинхронизации.
В принципе можно реплицировать и все базы, но раньше репликация только по этой одной базе работала исправно. Проблема появилась после того как однажды репликация "сломалсь" и я решил запустить ее заново(ресет на мастере и слейве, затем сдлал бекап на мстере и залил его на слейв и после - старт всего с нуля).
Неактивен
Как-то меня смущает Ваша фраза, что работала исправно. Работать не должна
была: когда Вы находитесь в другой базе, изменения не будут применяться при
включенном фильтре replicate_do_db. В крайнем случае, можно включить
replicate-wild-do-table=my_db.*, этот способ не будет игнорировать такие запросы.
Рассинхронизация в любом случае уже есть, реплику прийдется переналить.
Неактивен
Возможно я что-то не так описал. Ситуация такая:
На мастере есть база my_db. В нее пишутся(и читаются) данные.
На слейве в качестве бекапа есть капия той же my_db.
Настроена репликация именно по базе my_db, поэтому и стоит replicate_do_db=my_db.
По поводу рассинхронизации:
После синхронизации я в несколько разных таблиц на мастере делал инсерт, но на слейве данные не появились. После всех тестов я тестовые данные удалил. То есть на данный момент базы идентичны. Зачем переналивать реплику? Сделать ресеты мстера и слейва для обнуления бин-логов будет недостаточно?
Но вопросы рассинхронизации второстепенны. Так и непонятно почему данные не пишутся в реплику несмотря на то что по данным SHOW SLAVE STATUS все в порядке и в бин-логе есть запросы с мастера.
Неактивен
Наверное, это я плохо объяснил. Вот пример:
1. На мастере помимо my_db есть your_db.
2. Я подключаюсь клиентом и выполняю следующие команды:
a. USE your_db;
b. INSERT INTO my_db.statistics SELECT COUNT(*) FROM logtable;
3. Этот запрос не будет применен на реплике, потому что выполнен
2a и your_db ≠ my_db, который вписан в replicate_do_db.
Попробуйте добавить тестовые данные на мастере, и посмотрите, изме-
нится ли положение в двоичных журналах на реплике.
Неактивен
paulus, спасибо за участие и попытку помочь, но у меня выяснились новые обстоятельства:
Так и не добившись запуска репликации, я перед выходными запустил скрипты создающие записи в базе на мастере и в понедельник обнаужил что все что было добавлено за эти пару дней на мастере есть и на реплике. Т.е. репликация отработала. В том числе на реплике появились и тестовые данные, которые я вводил на мастере ранее.
Порадовавшись что все заработало - на всякий случай сделал еще одну тестовую запись на мастере и полез на реплику смотреть все ли нормально отработало. Но обнаружил что этой новой записи на слейве нет. Хотя на мастере параллельно идет нормальный рабочий процесс, данные пишутся в основную таблицу и нормально реплицируются на слейв.
Замечание: тестовые данные я добавлял в небольшую таблицу (3 колонки и изначально было 2 записи), но в основную не добавлял.
Вопросы:
В чем может быть дело?
Есть ли при репликации приоритеты или что-то в этом роде?
Почему данные могут не реплицироваться в режиме реального времени для определенных таблиц, в ситуации когда для других таблиц репликация происходит абссолютно нормально?
Неактивен
Репликация всегда идет в один поток. Если параллельно льются данные
из других баз, значит, должны были приехать и ваши данные. Больших
причин может быть две: изменение не попадает в двоичный журнал или
изменение не применяется на реплике.
Причины первого: плохие настройки binlog-* на мастере или включенный
sql_log_bin = 0 в потоке, который выполняет запрос.
Причины второго: плохие настройки replicate-* или slave-skip-* на реп-
лике.
Неактивен
Спасибо
Неактивен
Здравствуйте,
есть такая же проблема , данные не реплицируются, в бин логе на слейве есть запросы
SHOW SLAVE STATUS:
Неактивен
А в чем проявляется, что данные не реплицируются?
Неактивен
