Репліки читання D1 мали затримку у 6 секунд
Репліка читання D1 у Токіо відстала від запису в Північній Америці на 6,1 секунди.
Я дізнався про це завдяки трекеру, який обмежував кількість хибних показів. У документації згадується узгодженість у кінцевому підсумку (eventual consistency). Проте там не вказано конкретний час, на який варто орієнтуватися при плануванні.
Я створив зонд для перевірки застарілості даних (staleness probe), щоб дізнатися реальні цифри. Зонд записує рядок із UUID та epoch. Він опитує репліку, доки рядок не з'явиться, а потім фіксує затримку.
Результати 200 зондів в Азії:
- p50: 800 мс
- p95: 3 400 мс
- p99: 6 100 мс
Затримка є високою, якщо ваш primary знаходиться в Північній Америці, а користувачі — в Азії.
Я також зіткнувся з помилкою схеми. Міграція виконалася на primary. Worker перезапустився. Перші запити потрапили на репліку ще до того, як туди надійшла нова таблиця. Помилка вказувала на те, що таблиця не існує. Таблиця була, але репліка відставала.
Я вирішив це, перенаправляючи запити в обхід затримки. Я не борюся з нею.
Ось мій дизайн:
- Записуючий вузол (writer) додає written_at epoch до рядка.
- Записуючий вузол додає заголовок X-D1-Written-At до відповіді.
- Читаючий вузол (reader) порівнює цей заголовок із даними з репліки.
- Якщо дані репліки старіші за заголовок, читаючий вузол перемикається на KV.
KV працює швидше ніж за 500 мс у тому ж регіоні. Він безкоштовний для до 10 млн читань на день. Це забезпечує дешевий спосіб отримання свіжих