мне эта магия не нравится, хочется обойтись без неё. учитывая, как призрачно всё в этом мире бушующем, не хочется когда-нибудь в будущем думать о том, как эту магию расколдовывать.
соответственно, если у нас БД вырастает больше RAM одной из нод, то мы начинаем выбирать, какие таблицы мы будем хранить, а с какими мы потенциально будем развлекаться в случае краха того хоста, на котором они лежат. а у этих таблиц (которые в RAM и которые на диске одной из нод) могут быть ключи перекрестные... это я размышляю вслух. что-то не весело получается, учитывая размеры БД и объем RAM - её пускай и 48гиг, но она не растет, а БД очень даже.
Просто не знаю тонкостей, но имеет ли вообще смысл применять тут кластер на основе mysql ndb cluster. Если есть три ноды. То процесс более без болезненный это сделать мастер и два слейва, и уже распределять запросы на изменения к мастеру, а чтение рулить на слейв и один из них и бэкапить. Или как написано ниже, можно посмотреть в сторону групповых репликаций.
прихожу к мнению, что надо оставить так же, как есть сейчас (master-slave репликация). получается, что со времен mysql 4.0 легче удобнее и надежнее не стало.
галера это синхронная репликация, это значит что при записи нода станет работать медленнее потому что будет ждать отклика других нод.
если приложение изначально не написано с учетом галеры, то возможно появятся новые необъяснимые ошибки, потому что поведение блокировок изменилось. типа меняем одну и туже строку с двух нод: ses1 -> node1: update t set f0=6 where pk=1 ses2 ->node2: update t set f0=66 where pk=1 ses2 ->node2: commit success ses1 ->node1: commit fail в случае одной ноды, вторая сессия не сможет изменить и зависнет на блокировке.
да, столкнулись, и с бекапом, и что самое главное с восстановлением. было это еще когда БД была 30гиг, но и серверы тогда были не то что сейчас.
бекапим базу скриптом, 1 таблица = 1 файл, чтобы иметь возможность сначала быстро восстановить критичные для продукта таблицы, а потом уже доливать большие некритичные таблицы. так время восстановления работы продукта в критичной его части удается сократить где-то до получаса вместо 3-4 часов на всю БД.
Я серьезно, посмотрите на xtrabackup, он вам сделает копию всех баз сразу. А восстанавливается это просто копией полученного каталога /var/lib/mysql . Со всеми пользователями во всех базах, хранимками, внешними индексами и прочим. После того, как разберетесь, как он работает и как восстанавливать данные ставите себе xtrabackup-manager , настраиваете еженедельный полный и ежедневный инкрементальный бакапы и радуетесь жизни. Подумав, прикручиваете мониторинг к этим процессам и тогда уже точно радуетесь. У меня в двух местах такое решение уже несколько лет работает. Да, надо время от времени проверять как восстанавливаются бакапы, но это уже гораздо проще. Проблема только в восстановлении отдельных таблиц, но всегда можно развернуть всю базу и отдать нужную табличку из консистентного бакапа.
спасибо за наводку, но у нас всё тупо, без пользователей, хранимок, внешних индексов и прочего. одна тупая БД на 50 гигов. и какое-то решение по бекапу тут будет лишним. и главное как раз иметь возможность быстро восстановить десять первых "небольших" таблиц, чтобы запустился сервис. но за наводку спасибо, буду иметь ввиду.
Comments 19
(The comment has been removed)
Reply
(The comment has been removed)
Reply
Reply
Reply
Если есть три ноды. То процесс более без болезненный это сделать мастер и два слейва, и уже распределять запросы на изменения к мастеру, а чтение рулить на слейв и один из них и бэкапить. Или как написано ниже, можно посмотреть в сторону групповых репликаций.
Reply
получается, что со времен mysql 4.0 легче удобнее и надежнее не стало.
Reply
MySQL уже почти выпустил "настоящий" кластер. Group Replication уже есть в 5.7.18, обещали скоро родить прокси.
http://mysqlhighavailability.com/tag/mysql-group-replication/
https://dev.mysql.com/doc/refman/5.7/en/mysql-innodb-cluster-userguide.html
Reply
Reply
Reply
написал UPD к посту.
Reply
если приложение изначально не написано с учетом галеры, то возможно появятся новые необъяснимые ошибки, потому что поведение блокировок изменилось.
типа меняем одну и туже строку с двух нод:
ses1 -> node1: update t set f0=6 where pk=1
ses2 ->node2: update t set f0=66 where pk=1
ses2 ->node2: commit success
ses1 ->node1: commit fail
в случае одной ноды, вторая сессия не сможет изменить и зависнет на блокировке.
Reply
Reply
Reply
бекапим базу скриптом, 1 таблица = 1 файл, чтобы иметь возможность сначала быстро восстановить критичные для продукта таблицы, а потом уже доливать большие некритичные таблицы. так время восстановления работы продукта в критичной его части удается сократить где-то до получаса вместо 3-4 часов на всю БД.
Reply
А восстанавливается это просто копией полученного каталога /var/lib/mysql . Со всеми пользователями во всех базах, хранимками, внешними индексами и прочим.
После того, как разберетесь, как он работает и как восстанавливать данные ставите себе xtrabackup-manager , настраиваете еженедельный полный и ежедневный инкрементальный бакапы и радуетесь жизни.
Подумав, прикручиваете мониторинг к этим процессам и тогда уже точно радуетесь.
У меня в двух местах такое решение уже несколько лет работает.
Да, надо время от времени проверять как восстанавливаются бакапы, но это уже гораздо проще.
Проблема только в восстановлении отдельных таблиц, но всегда можно развернуть всю базу и отдать нужную табличку из консистентного бакапа.
Reply
Reply
Leave a comment