В версиях 1.x и 2.x у Tarantool не было отдельного файла-конфига. Экземпляр настраивался императивно, прямо в коде, через единственную точку входа - функцию box.cfg{}. Эта функция делает сразу две вещи: применяет параметры (память, порт, каталоги, журналирование) и запускает движок базы данных. До первого вызова box.cfg экземпляр - это просто Lua-интерпретатор без хранилища, спейсов и сети. После вызова появляется box.space, открывается бинарный порт, запускается WAL и работают репликация и снапшоты.
Сценарий запуска складывают в обычный Lua-скрипт. Исторически его называют init.lua. Tarantool просто исполняет этот скрипт построчно: сначала box.cfg{}, потом всё прикладное - создание спейсов, индексов, функции, назначение прав. Никакой магии: это последовательная Lua-программа, где box.cfg - первый значимый шаг.
Механика: как box.cfg устроен внутриКлючевая идея legacy-трека: конфигурация - это вызов функции, а не данные. Поэтому вы можете считать значения из переменных окружения, ветвиться по if, собирать параметры в цикле. Гибко, но проверка корректности и единый источник правды полностью на вас.
Два режима вызова. box.cfg без скобок (как свойство) возвращает таблицу текущих значений всех параметров - удобно для интроспекции. box.cfg{...} со скобками (это синтаксический сахар Lua для вызова функции с одним табличным аргументом) применяет конфигурацию.
Первый вызов = recovery. Самый первый box.cfg{} после старта процесса запускает процедуру восстановления. Tarantool заходит в work_dir, находит в memtx_dir последний снапшот (.snap), загружает его в память, затем доигрывает все .xlog из wal_dir, записанные после снапшота. Так memtx-данные целиком воссоздаются из снапшота плюс журнала. Только после этого экземпляр готов обслуживать запросы. То есть box.cfg{} - это не просто присваивание настроек, а полноценная инициализация движка с чтением диска.
Динамические и статические параметры. Большинство параметров динамические: повторный box.cfg{} меняет их на лету. Часть - только на старте (Dynamic: no), например listen меняется, а memtx_dir или wal_mode - нет. Особый случай memtx_memory: динамический, но увеличивать можно, уменьшать нельзя (память уже роздана аллокатором small).
Переменные окружения. У каждого параметра есть зеркало в окружении с префиксом TT_ (TT_LISTEN, TT_MEMTX_MEMORY). Это пригодится при сравнении с 3.x, где переменные окружения - штатный способ переопределения.
Запуск init.lua: box.cfg, параметры, recovery
Ключевой код: минимальный init.lua
Код: Выделить всё
-- init.lua: запускаем как tarantool init.lua
box.cfg{
listen = 3301, -- бинарный порт, по умолчанию nil
memtx_memory = 512 * 1024 * 1024, -- 512 МБ под тапл-данные memtx
work_dir = '/var/lib/tarantool/app',
wal_dir = 'wal', -- относительно work_dir
memtx_dir = 'snap', -- .snap отдельно от .xlog
wal_mode = 'write', -- write|fsync|none
log = 'file:tarantool.log',
log_level = 5, -- info
checkpoint_interval = 3600, -- автоснапшот раз в час
}
-- прикладная часть выполняется ПОСЛЕ box.cfg
box.once('schema_v1', function()
local s = box.schema.space.create('users')
s:format({{name='id', type='unsigned'}, {name='name', type='string'}})
s:create_index('pk', {parts = {'id'}})
box.schema.user.create('app', {password = 'secret', if_not_exists = true})
box.schema.user.grant('app', 'read,write', 'space', 'users')
end)
Изменить параметр на лету (из консоли):
Код: Выделить всё
box.cfg{ memtx_memory = 1024 * 1024 * 1024 } -- увеличили лимит памяти
box.cfg.listen -- посмотреть текущее значение
box.cfg{ checkpoint_count = 4 } -- хранить 4 последних снапшота
box.snapshot() -- ручной чекпойнт прямо сейчас
Код: Выделить всё
ПАРАМЕТР НАЗНАЧЕНИЕ ПО УМОЛЧАНИЮ ДИНАМИЧ.
listen бинарный порт/URI nil да
memtx_memory память под таплы memtx 256 МБ да (только рост)
work_dir рабочий каталог (chdir) текущий нет
memtx_dir где лежат .snap "." нет
wal_dir где лежат .xlog "." нет
wal_mode write / fsync / none write нет
read_only режим только чтение (реплика) false да
checkpoint_interval авто-снапшот, сек 3600 да
checkpoint_count сколько снапшотов хранить 2 да
log / log_level назначение и уровень логов stderr / 5 частично
net_msg_max лимит сетевых сообщений 768 да
В Tarantool 3.0+ настройка в коде объявлена legacy. Рекомендуемый способ - декларативный YAML-файл, где описывается вся топология кластера, а не один экземпляр. Те же параметры превращаются в иерархию ключей. Сравните один в один:
Код: Выделить всё
# config.yaml - декларативный трек 3.x
credentials:
users:
app:
password: 'secret'
roles: [super]
iproto:
listen:
- uri: '127.0.0.1:3301' # аналог box.cfg{listen=3301}
memtx:
memory: 536870912 # аналог memtx_memory = 512 МБ
wal:
mode: write # аналог wal_mode
groups:
group-001:
replicasets:
rs-001:
instances:
instance-001: {}
Частые заблуждения и грабли
- "box.cfg только настраивает". Нет: первый вызов запускает recovery с чтением снапшота и журнала. На большой базе он может идти минуты.
- Снести .xlog "чтобы освободить место". Без снапшота за нужный момент удаление .xlog ломает восстановление: memtx живёт только в памяти, его источник правды - снапшот плюс журнал.
- Ждать, что memtx_memory уменьшится на лету. Он только растёт. Для снижения нужен рестарт. И помните: это лимит на таплы, индексы и соединения едят память сверх него.
- wal_mode = none на мастере. Узел без WAL не может быть мастером репликации и теряет данные при падении. Используйте только для временных или кеш-сценариев.
- Относительные пути. wal_dir и memtx_dir считаются относительно work_dir, а work_dir выполняет chdir после старта. Путаница тут - классическая причина "база не находит файлы".
- background = true под tt. Не включайте фоновый режим для приложений, запускаемых утилитой tt - демонизацией управляет supervisor.
Создайте файл init.lua: пропишите listen = 3301, memtx_memory = 256 МБ, отдельные wal_dir и memtx_dir, checkpoint_interval = 60. Запустите tarantool init.lua. В консоли выполните box.cfg (без скобок) и найдите свои значения. Затем выполните box.cfg{checkpoint_count = 3} и box.snapshot(). Проверьте, что в каталоге memtx_dir появился свежий .snap, а в wal_dir - .xlog. Остановите и запустите экземпляр заново - убедитесь, что данные восстановились (это и есть recovery в действии).
Контрольные вопросы
- Что именно происходит при ПЕРВОМ вызове box.cfg{} помимо применения параметров, и из каких файлов восстанавливаются memtx-данные?
- Почему memtx_memory можно увеличить динамически, но нельзя уменьшить без рестарта?
- Чем отличается императивная настройка через box.cfg{} в init.lua от декларативной через config.yaml в 3.x - и куда в итоге сводится YAML внутри?
- Как соотносятся work_dir, wal_dir и memtx_dir, и почему относительные пути считаются именно от work_dir?