Масштабирование платежной системы Etsy с помощью Vitess: Часть 3 – Снижение риска переключения

Платежи Etsy перевели 40 миллиардов строк из 23 таблиц в среду Vitess с разбивкой на сегменты, используя vindexes для разбивки данных. В этой статье мы уделяем особое внимание ошибкам, которые могут возникать во время перехода. Важно понимать режимы транзакций Vitess. Одиночный режим поддерживает атомарность, но многорежимный режим может привести к частичным фиксациям. Двухфазный режим фиксации является экспериментальным и не рекомендуется. Обратная VReplication обеспечивает синхронизацию данных между не разбиваемым и разбиваемым ключевым пространством после перехода. Она может нарушиться из-за соблюдения уникального ключа, требуя исправлений, таких как удаление строк или ручное обновление столбца Pos. Разбросанные запросы, в которых ключ разбивки опущен в клаузе WHERE, могут привести к чрезмерному объему запросов и возможным простоям. Vitess теперь предлагает флаг --no_scatter для предотвращения таких запросов. Неподдерживаемые запросы могут терпеть неудачу после перехода. Тщательное тестирование в среде разработки является необходимым для выявления и решения таких запросов. Другие потенциальные ошибки включают ошибки, связанные с неподдерживаемыми SQL-конструкциями, которые могут быть решены путем обновления до более новых версий Vitess. Несмотря на эти риски, переходы в целом обратимы, если обратная VReplication работает должным образом. Однако влияние любого нарушения работы следует тщательно рассматривать.