Комментарии 11
Про «идиотов»: загуглил — вот вторая ссылка. И в чём здесь «АД»?
Я понял, что все печально с реализацией, наступив на часть граблей из статьи. Раньше бы ее прочитал — думаю, ошибок было бы меньше. Надеюсь, статья кому-то еще пригодится)
С тех пор у меня в голове закрепилось, что репликация в MySQL убогая. Спасибо, что раскрыли некоторые не очевидные моменты
С тех пор у меня в голове закрепилось, что репликация в MySQL убогая. Спасибо, что раскрыли некоторые не очевидные моменты
Она не убогая, она под строго ограниченные задачи. Это не standby, это не бакап, это именно «один пишет — многие читают». Распараллеливание нагрузки на чтение.
> она под строго ограниченные задачи
В строго ограниченной среде. Так, например, если вдруг происходит рассинхронизация, и slave где-то остановился, то тебе надо сначала узнать о том, что твои slav'ы выдают устаревшие данные, потом понять, что репликация остановилась из-за какого-то сбоя. И хорошо если bin-log еще жив, и можно просто попробовать указать точку, с которой продолжить запись(и да, нужно будет дождаться завершения синхронизации неизвестно сколько). Если же bin-log уже перезаписался по 2 раза, то реплики уже слишком далеко от оригинала, и единственный выход — делать полную копию master-базы на определенный момент и импортировать её, вручную поправляя точку старта для slave.
Как правильно отметили в статье, MySQL не хватает инструментов для мониторинга всего этого зоопарка, а наличие сторонних надстроек я считаю недоработкой MySQL. Я считаю, что изначально одна должна была уметь такие базовые вещи, чтобы всё могло работать более-менее.
В строго ограниченной среде. Так, например, если вдруг происходит рассинхронизация, и slave где-то остановился, то тебе надо сначала узнать о том, что твои slav'ы выдают устаревшие данные, потом понять, что репликация остановилась из-за какого-то сбоя. И хорошо если bin-log еще жив, и можно просто попробовать указать точку, с которой продолжить запись(и да, нужно будет дождаться завершения синхронизации неизвестно сколько). Если же bin-log уже перезаписался по 2 раза, то реплики уже слишком далеко от оригинала, и единственный выход — делать полную копию master-базы на определенный момент и импортировать её, вручную поправляя точку старта для slave.
Как правильно отметили в статье, MySQL не хватает инструментов для мониторинга всего этого зоопарка, а наличие сторонних надстроек я считаю недоработкой MySQL. Я считаю, что изначально одна должна была уметь такие базовые вещи, чтобы всё могло работать более-менее.
В постгрес имхо репликация не менее убогая, хоть и надежная. Приходиться с этим жить.
имхо — в MS SQL она вообще отвратительная))
Есть некоторое количество интересующих вопросов.
Возможны ли реплики между mysql и mariadb?
Возможны ли реплики между разными версиями баз? Что будет, если мастер более новый — а слэйв не обновили, или слэйв более новый — а мастер не обновили?
Возможен ли режим, при котором данные поднимаются частично? Например, нода умерла на 3 года, за это время 90% данных на других нодах было обновлено или стерто, а логи этих трех лет давно затерты. Есть ли механизм, позволяющий, на тех нодах, что все 3 года работали — стирать слишком старые логи, несмотря на то, что они не зареплециловались куда-то, а на починеной ноде — подхватить новые данные и работать дальше с ними?
В статье упоминается semi-sync и delayed slave, GTID — что это такое, в двух словах?
Почему pull-based репликация — это плохо?
Я так и не понял — есть какой-то нормальный способ переключаться автоматически на слэйв в том случае, если сдыхает мастер? Или это только руками?
Возможны ли реплики между mysql и mariadb?
Возможны ли реплики между разными версиями баз? Что будет, если мастер более новый — а слэйв не обновили, или слэйв более новый — а мастер не обновили?
Возможен ли режим, при котором данные поднимаются частично? Например, нода умерла на 3 года, за это время 90% данных на других нодах было обновлено или стерто, а логи этих трех лет давно затерты. Есть ли механизм, позволяющий, на тех нодах, что все 3 года работали — стирать слишком старые логи, несмотря на то, что они не зареплециловались куда-то, а на починеной ноде — подхватить новые данные и работать дальше с ними?
В статье упоминается semi-sync и delayed slave, GTID — что это такое, в двух словах?
Почему pull-based репликация — это плохо?
Я так и не понял — есть какой-то нормальный способ переключаться автоматически на слэйв в том случае, если сдыхает мастер? Или это только руками?
Многие беды которые есть в Мастер-Мастер в multimaster исправлены.
За статью спасибо.
За статью спасибо.
1. А сколько можно поставить слейвов, чтобы не тупили апдейты (в т.ч. синхронные)?
2. Некоторые считают, что репликация больше для надежности, чтобы сервис работал, если мастер упадет.
3. Бекапы не с помощью репликации предлагается делать на уровне ФС? rsync-ом? Он умеет синхронизироваться по кускам? hot-бекапы? Или на уровне sql. Может глюк, но на винде что mysql, что postgres ужасно тупят на восстановлении из SQL.
4. Какой максимальный достигнутый размер базы на одном сервере?
5. Кто что еще опишет Galera и NDB? :)
2. Некоторые считают, что репликация больше для надежности, чтобы сервис работал, если мастер упадет.
3. Бекапы не с помощью репликации предлагается делать на уровне ФС? rsync-ом? Он умеет синхронизироваться по кускам? hot-бекапы? Или на уровне sql. Может глюк, но на винде что mysql, что postgres ужасно тупят на восстановлении из SQL.
4. Какой максимальный достигнутый размер базы на одном сервере?
5. Кто что еще опишет Galera и NDB? :)
> UPDATE users SET bonus=bonus+100
> UPDATE users SET disabled=1 WHERE last_login < UNIX_TIMESTAMP(NOW())-100*86400
Вижу Мсье играется торрент-трекерами на PHP ;)
(узнаю структуру базы, либо так совпало ну совсем...)
> UPDATE users SET disabled=1 WHERE last_login < UNIX_TIMESTAMP(NOW())-100*86400
Вижу Мсье играется торрент-трекерами на PHP ;)
(узнаю структуру базы, либо так совпало ну совсем...)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как устроена MySQL-репликация