...
Slave_IO_Running: Yes
Slave_SQL_Running: No
...
Last_Errno: 1062
Last_Error: Error 'Duplicate entry '357966-1281124202pupZEi' for key 'PRIMARY'' on query. Default database: 'site'. Query: 'insert into Ru_Talk_Ban set i_id='357966', session_id='1281124202pupZEi', vote='minus''
Похоже, сама репликация при этом идет, но сервер типа не работает.
Понятно, что есть
Skip_Counter: 0
Но в бинлоги идет то, что выполнено на мастере успешно.
От чего вообще такое вылезает, как это фиксить автоматом и что вообще делать правильнее в таком случае? Сносить базу, архивировать на мастере, заливать с нуля и снова поднимать репликацию?
Чтобы заново создать реплику:
- мастер в read only
- дамп базы
- запоминаем позицию binlog
- мастера можно в rw
- заливаем дамп
- поднимаем реплику с нужной позиции
Делал последовательность, знаю. Меня больше интересует, как этого избежать в дальнейшем и по максимуму ускорить восстановление.
Было не так давно load data from master, но сейчас ругается "в будущих версиях будет убрано". А жаль.
Делал последовательность, знаю. Меня больше интересует, как этого избежать в дальнейшем и по максимуму ускорить восстановление.
Было не так давно load data from master, но сейчас ругается "в будущих версиях будет убрано". А жаль.
Это ошибка -- где-то попались кривые данные -- кто-то записал в реплику, первоначально была поднята с протухшими данными. Других проблем с MySQL (в отличии от PostgreSQL) обычно не бывает.
Делал последовательность, знаю. Меня больше интересует, как этого избежать в дальнейшем и по максимуму ускорить восстановление.
Было не так давно load data from master, но сейчас ругается "в будущих версиях будет убрано". А жаль.
Это ошибка -- где-то попались кривые данные -- кто-то записал в реплику, первоначально была поднята с протухшими данными. Других проблем с MySQL (в отличии от PostgreSQL) обычно не бывает.
То есть если потом превратить реплику с мастер-мастер, это будет корректная работа?
А что с постгресом не так? В доках на тот же заббикс на 10к+ хостов постгрес советовали, а на меньшее - мускуль..
И еще.. если у меня 4 базы надо реплицировать, получается, что надо сначала на все выставить flush tables with read lock, все 4 задампить, и только после этого отпускать? У нас же master_pos меняться будет иначе. Да и какой задавать тогда для старта, непонятно. А если баз 500? Это ж повеситься.
И как делать репликацию юзеров? Можно на системную повесить? (mysql которая)
И еще.. что повесить на реплику, чтобы она была RO? Причем так, чтобы при падении мастера ее можно было сделать мастером.
RO включается: SET GLOBAL read_only = ON;
Ну и отключается соответственно.
О, супер.
На время дампов -- самое то.
На время дампов лучше все-таки lock tables with read lock, нет?
Причём здесь мастер-мастер? Оно требуют наличия авто-инкремента во всех таблицах, либо очень аккуратная работа из приложений.
auto-increment-increment
auto-increment-offset
?
А есть возможность "вся запись на 1 сервер, а читать со всех"? mysql-proxy вроде поможет? Но говорят, у него с производительностью беда.
KiWi
Поставили задачу, как "выжить" в пики посещаемости, когда нагрузка поднимается на порядки (новостной портал в моменты всяких ЧП). Вспомнился amazon EC2+ прочие сервисы, если там запускать доп инстансы, при основном сервере "снаружи". Не доводилось общаться с ними?
KiWi
Поставили задачу, как "выжить" в пики посещаемости, когда нагрузка поднимается на порядки (новостной портал в моменты всяких ЧП). Вспомнился amazon EC2+ прочие сервисы, если там запускать доп инстансы, при основном сервере "снаружи". Не доводилось общаться с ними?
Писать в мастер, читать только с реплик. Над репликами поднять haproxy, например. Или ещё какой-либо метод балансировки.
Кешировать страницу(или часть) там, где она отдаётся(на 5 минут, например) -- текст новости обычно не меняется.
Писать в мастер, читать только с реплик. Над репликами поднять haproxy, например. Или ещё какой-либо метод балансировки.
С haproxy скорее всего будет проблема, сервера должны быть географически разделены (разные ДЦ). Там еще и отказоустойчивость.. Если и будет работать, трафик по идее зашкалит.
А что по остальным вопросам?
RO включается: SET GLOBAL read_only = ON;
Ну и отключается соответственно.
О, супер.
На время дампов -- самое то.
На время дампов лучше все-таки lock tables with read lock, нет?
Note
If you use ALTER TABLE on a locked table, it may become unlocked. For example, if you attempt a second ALTER TABLE operation, the result may be an error Table 'tbl_name' was not locked with LOCK TABLES. To handle this, lock the table again prior to the second alteration. See also Section B.5.7.1, “Problems with ALTER TABLE”.
Не факт.
Причём здесь мастер-мастер? Оно требуют наличия авто-инкремента во всех таблицах, либо очень аккуратная работа из приложений.
auto-increment-increment
auto-increment-offset
?
Именно.
Но даже при этом могут вылезти странности.
А есть возможность "вся запись на 1 сервер, а читать со всех"? mysql-proxy вроде поможет? Но говорят, у него с производительностью беда.
Насчёт этого ничего не знаю. У нас весь софт знает о том, какие базы есть и подключается напрямую к ним(это если говорить о MySQL).
