от 29.12.2020, что добавлена поддержка этих параметров в argparse, но куда и как передавать эти аргументы не очень понятно.
https://www.tarantool.io/en/doc/latest/how-to/replication/repl_sync/ Синхронность репликации настраивается на уровне спейса. По умолчанию вроде синхронная.
По умолчанию -- вряд ли
Его точно сдруживали с синхрой, поэтому должен. Но пользователей не очень много обкатывало. Если что-то не так -- заходите жаловаться
Получается, что space можно сделать синхронным, а у sequence нет такой настройки и он может "отъехать" назад на размер cache в случае аварийной потери мастера?
забудьте про sequence + репликация.
Интересный поворот. Почему, если не секрет? :)
емнип, состояние сиквенса на слейвы не реплицируется.
Сиквенс успешно переживает перезагрузки. Учитывая, что весь стейт живёт в snapshot+wal, делаю вывод, что сиквенс попадает в wal, и, соответственно, реплицируется на реплики. Поправьте, если я неправ. Осталось только понять, как делать его надежным=синхронным...
На слейвы реплицируется, но если планируется несколько репликасетов, между ними уже не будет никакой синхронизации и сиквенс просто пойдет параллельно на каждом.
Поможет ли запрос сиквенсов всегда с мастера, отвечающего за bucket_id=1? Или в случае ребалансировки bucket_id может отъехать другому репликасету?
Не нужно выдумывать чушь, сиквенсы и шардинг несовместимы
Ну в принципе вариант в внешней выдачей всегда остаётся. Тот-же Twitter snowflake так и работает.
Обсуждают сегодня