Подключение и работа с Radix

Для работы с Radix используйте клиентскую программу redis-cli. Подключение осуществляется по адресу, заданному параметром advertise (или listen если публичный адрес не указан) для секции radix в файле конфигурации Picodata.

redis-cli -p 7301

Для корректной работы redis-cli и других клиентских приложений настройте авторизацию в Radix.

Перенос данных между кластерами

Обновление с предыдущей версии Radix

Миграция с версий Radix, ниже чем 1.0.0, невозможна. Обновление Radix 1.x.x на более новую версию поддерживается и происходит аналогично установке Radix с той разницей, что если в кластере ранее была включена предыдущая версия плагина, то её следует сначала отключить и лишь затем включить новую версию. Пример:

ALTER PLUGIN radix 1.0.6 DISABLE OPTION(TIMEOUT=30);
ALTER PLUGIN radix 1.1.1 ENABLE OPTION(TIMEOUT=30);

Миграция с помощью radix-cli

Данный способ подходит для переноса данных как из Redis в Radix, так и между двумя кластерами Radix. Это наш собственный инструмент миграции данных, который доступен через утилиту radix-cli, поставляемую вместе с плагином. Инструмент учитывает особенности некоторых старых версий Radix.

Минимальный пример использования утилиты:

$ <picodata_share_dir>/radix/1.0.6/radix-cli migrate redis://localhost:7379/1 redis://localhost:7301/15
⠏ Подключено к источнику Radix 0.11.8 cluster (Picodata 25.3.8)
⠏ Подключено к приёмнику Radix 1.0.6 cluster (Picodata 26.1.3-0-gc21b37df2)
[00:00:00] [========================================] 800/800 ключей
Перенесено 800 ключей за 329мс
Пропущено (существующих): 0
Пропущено (по TTL):       0
Не удалось: 0

Убедитесь, что во время миграции в источнике и приёмнике не выполняются модифицирующие операции над самими данными или их свойствами (например, TTL), так как это усложняет процесс миграции. В частности, состояние ключа на приёмнике невозможно будет предсказать если:

• источник содержит ключи-коллекции размера больше --collection-chunk-size (или его стандартного значения) и эти ключи модифицируются в процессе переноса
• приёмник содержит ключи-коллекции и они модифицируются кем-то кроме утилиты radix-cli

Также, при запуске миграции с параметром --overwrite утилита может удалить только что записанный ключ.

Перед началом миграции утилита печатает совет остановить запись в источник и приёмник, и ожидает ввода с клавиатуры: подтвердите запуск или нажмите Esc для отмены миграции. Обратите внимание:

• Ожидание ввода используется только при ручном запуске утилиты из терминала. Если утилита работает из скрипта или её вывод перенаправлен, совет просто печатается, и перенос идёт дальше.
• Флаг --yes отвечает за пользователя и убирает ожидание там, где терминал есть, а нажать клавишу некому (например, docker run -t).

Отдельное подтверждение нужно для --overwrite: без него существующие ключи приёмника пропускаются, а с ним — перезаписываются данными из источника без возможности восстановления. Поэтому утилита просит набрать имя picodata-кластера в приёмнике — чтобы случайно не перезаписать данные в чужом кластере.

--overwrite	--yes	Запуск	Поведение
нет	любой	любой	существующие ключи приёмника пропускаются, подтверждения нет
да	нет	из терминала	предупреждение о перезаписи, затем ввод имени кластера
да	да	любой	предупреждение печатается, перенос идёт без вопросов
да	нет	из скрипта	перенос не начинается: подтвердить некому, нужен --yes

Имя кластера утилита берёт из поля picodata_cluster_name в секции radix ответа INFO. Имеются два исключения:

• Radix, который это поле не отдаёт (сборки до 0.9.0), не даст набрать имя, поэтому --overwrite для него тоже требует --yes;
• приёмник, который не является Radix (обычный Redis), подтверждения не требует.

Понижение версии плагина

При попытке откатиться на более старую версию плагина командой ALTER PLUGIN radix MIGRATE TO <старая_версия> Picodata может вернуть ошибку вида:

more migrations have already been applied (18) than are in the manifest (17)

Это происходит, когда текущая (новая) версия плагина содержит больше миграций, чем версия, на которую вы откатываетесь: список применённых миграций в Picodata общий для всех версий плагина, и проверка «применено больше, чем в манифесте целевой версии» срабатывает ещё до выполнения отката.

Утилита radix-cli migrate-down снимает это ограничение: она откатывает DOWN-секции «лишних» миграций (дельты между текущим набором и набором целевой версии) и удаляет их записи из служебной таблицы _pico_plugin_migration. После этого MIGRATE TO и последующий ENABLE проходят корректно.

Примечание

Целевая (старая) версия плагина должна быть уже установлена в кластере (ALTER PLUGIN radix ADD <старая_версия> ...) — из неё берётся авторитетный список миграций.

Порядок действий.

1. Предпросмотр (по умолчанию — ничего не выполняется, только печатается план):

   radix-cli migrate-down \
     "postgres://admin:<пароль>@<хост>:<pg-порт>/picodata?sslmode=disable" \
     --to <старая_версия> \
     --plugin-dir <каталог share picodata, содержащий radix/<версия>/...>
   

2. Внимательно проверьте план. DOWN-секция может содержать деструктивные операции (DROP TABLE), уничтожающие данные, добавленные новой версией. Откатываются только миграции дельты; общий префикс миграций не трогается, поэтому данные из него сохраняются.

3. Выполните откат, добавив флаг --apply:

   radix-cli migrate-down \
     "postgres://admin:<пароль>@<хост>:<pg-порт>/picodata?sslmode=disable" \
     --to <старая_версия> --plugin-dir <...> --apply
   

4. Завершите понижение версии с помощью следующих SQL-запросов:

   ALTER PLUGIN radix MIGRATE TO <старая_версия>;
   ALTER PLUGIN radix <старая_версия> ENABLE;
   

Если дельта пуста (целевая версия имеет тот же набор миграций), команда ничего не делает и сообщает об этом — понижение версии можно выполнять обычным способом.