Приходилось ли работать с репликами
Что проверяют
Понимаете ли вы, что даёт реплика и чем за неё платят. Вопрос выглядит простым, но за ним идёт разговор про отставание, переключение при сбое и про то, как всё это переживает приложение на Go.
Как отвечать
Сначала уточните, о каких репликах речь: о репликах базы или об экземплярах самого сервиса. Если о базе, разложите так:
- асинхронная репликация: основной узел не ждёт реплику, отставание измеряется и растёт под нагрузкой, при потере основного узла часть подтверждённых транзакций теряется;
- синхронная: потери нет, но коммит ждёт подтверждения реплики, а недоступная синхронная реплика останавливает запись, если не настроен запасной вариант;
- реплика для чтения разгружает основной узел, но всегда отдаёт данные с задержкой.
Со стороны Go говорите конкретикой: два пула соединений или маршрутизация через прокси, чтение собственных свежих записей отправляется на основной узел, у каждого запроса свой context с таймаутом, повторы только для идемпотентных операций, проверка живости соединений в пуле. Переключение при сбое делает не приложение, а отдельный механизм с кворумом; от приложения требуется пережить обрыв всех соединений и переподключиться.
Где спотыкаются
Переводят на реплики все чтения подряд. Пользователь сохраняет форму, следующий запрос уходит на отставшую реплику, и данные выглядят пропавшими. Лечится маршрутизацией по признаку недавней записи, а не увеличением числа реплик.
Второе: считают реплику резервной копией. Ошибочное удаление без условия доедет до реплики за доли секунды, спасают только настоящие бэкапы и восстановление на момент времени.
Третье: не готовят приложение к переключению. Соединения в пуле висят на старом узле, запросы без таймаута ждут бесконечно, а повтор неидемпотентной записи после обрыва создаёт дубль платежа.