репикации. Я правильно понимаю, что настройка самой репликации в box.cfg аналогична по параметрам асинхронной(юзер, пароль, права юзера на репликацию, адреса удаленных нод реплики и т.п.) и сама по себе синхронность включается на уровне спейса? Или есть какой то вариант, когда все спейсы будут синхронно реплицированы? Ну т.е. за этим не надо следить при создании спейса.
P.S. В доках много разрозненной инфы, но вот не складывается в одну кучу у мея никак чтото 😁 https://www.tarantool.io/ru/doc/latest/how-to/replication/repl_sync/#how-to-repl-sync
Да, так же настраивается box.cfg.replication, Для кворума есть ручка box.cfg.replication_synchro_quorum Синхронными будут транзакции, трогающие синхронный спейс. Можно сделать space:alter{is_sync=true} Если хочется использовать синхру без выборов, на назначенном лидере нужно звать box.ctl.promote(), чтобы он мог писать
Т.е. синхронная репликация фактически это "надстройка" над асинхронной? И соответственно оставляет возможность асинхронной репликации некоторых спейсов, которым при создании не был указан is_sync=true( и как я понял у синхронной выше "приоритет", раз синхронные транзакции блокируют асинхронные)?
Да, но асинхронной репликацией в присутствии синхронной нужно пользоваться осторожно. Можно налететь на проблемы при смене лидера, которые сейчас решаются только ребутстрапом старой ноды. Мы думаем, как это починить.
Я читал про эти проблемы. Планируем мухи отдельно, котлеты отдельно(синхр и асинхр), я для полнимания просто спросил. Спасибо!
А вы не планируете сделать мульти мастер с синхронной репликации?
Нет, не планируем. А вам зачем?
Синхронизация настроек системы, которые продублированы на нескольких серверах
Понял. А форвардить запросы на лидера подходит?
какие планы по системным спейсам?
Предположительно, будем считать их синхронными, когда синхронная очередь кому-то принадлежит
тоесть посути типа всегда в нормальном режиме ?
Наверное нет. Лидер может быть не доступен. А кто новый хз. Сейчас мы используем асинхронную репликацию с перебором серверов
а у вас самописный сбор и управление кластером?
У нас асинхронная репликация на 3-х серверах. Зная что любой из серверов может уйти в небытие, процедура пишет в один из них, если он не доступен, перебирает последовательно все, и в первый доступный пишет.
А конфликты триггером решаете?
мы триггеры не используем вообще. И время от времени проверяем целостность данных в реплике, ибо нет 100% доверия.
Обсуждают сегодня