Top.Mail.Ru
Запуск сервера с репликацией | Tarantool
 
Справочники / Детали реализации / Запуск сервера с репликацией
Справочники / Детали реализации / Запуск сервера с репликацией

Запуск сервера с репликацией

Запуск сервера с репликацией

Помимо вышеописанного процесса восстановления, сервер должен предпринять дополнительные меры предосторожности, если включена репликация.

И снова процедура запуска начинается с запроса box.cfg{}. Одним из параметров запроса box.cfg может быть replication, в котором указываются источники репликации. Реплику, которая запускается сейчас с помощью box.cfg, мы будем называть локальной, чтобы отличать ее от других реплик в наборе реплик, которые мы будем называть удаленными.

#1. Если нет файла снимка .snap, и не указано значение параметра „replication“, и cfg.read_only=false:
Локальная реплика предполагает, что она нереплицируемый обособленный экземпляр или же первая реплика в новом наборе реплик. Она сгенерирует новые UUID для себя и для набора реплик. UUID реплики хранится в спейсе _cluster (если только реплика не является анонимной). UUID набора реплик хранится в спейсе _schema. Поскольку снимок содержит все данные во всех спейсах, это означает, что снимок локальной реплики будет содержать UUID реплики и UUID набора реплик. Таким образом, когда локальная реплика позднее перезапустится, она сможет восстановить эти UUID после того, как прочитает файл снимка .snap.

#1a. Если нет файла снимка .snap, не указано значение параметра „replication“ и cfg.read_only=true:
Когда запуск экземпляра осуществляется с помощью an instance box.cfg({... read_only = true}), такая реплика не может быть первой в наборе реплик, потому что первая реплика должна быть мастером. Поэтому возникнет ошибка: ER_BOOTSTRAP_READONLY. Чтобы этого избежать, измените в настройке локального экземпляра read_only на false, или убедитесь, что удаленный экземпляр запускается первым и имеет UUID локального экземпляра в спейсе _cluster. Во втором случае, если произойдет ER_BOOTSTRAP_READONLY, выставите на локальном экземпляре большее значение box.replication_connect_timeout.

#2. Если нет файла снимка .snap, указано значение параметра „replication“, а в спейсе ``_cluster`` отсутствуют UUID других реплик:
Локальная реплика предполагает, что она не является обособленным экземпляром, но еще не входит в набор реплик. Сейчас она должна подключиться в набор реплик. Она отправит свой UUID реплики первой удаленной реплике из параметра replication, которая будет выступать в качестве мастера. Это называется «запрос на подключение». Когда удаленная реплика получает запрос на подключение, она отправляет в ответ:

  1. UUID набора реплик, в который входит удаленная реплика
  2. содержимое файла снимка .snap удаленной реплики.
    Когда локальная реплика получает эту информацию, она размещает UUID набора реплики в своем спейсе _schema, UUID удаленной реплики и информацию о подключении в своем спейсе _cluster, а затем создает снимок, который содержит все данные, отправленные удаленной репликой. Затем, если в WAL-файлах .xlog локальной реплики содержатся данные, они отправляются на удаленную реплику. Удаленная реплика получается данные и обновляет свою копию данных, а затем добавляет UUID локальной реплики в свой спейс _cluster.

#3. Если нет файла снимка .snap, указано значение параметра „replication“, а в спейсе ``_cluster`` есть UUID других реплик:
Локальная реплика предполагает, что она не обособленный экземпляр, а уже входит в набор реплик. Она отправит свой UUID реплики и UUID набора реплик всем удаленным репликам из параметра replication. Это называется «подтверждение связи при подключении». Когда удаленная реплика получает подтверждение связи при подключении:

  1. удаленная реплика сопоставляет свою версию UUID набора реплик с UUID, переданным в ходе подтверждения связи при подключении. Если они не совпадают, связь не устанавливается, и локальная реплика отобразит ошибку.
  2. удаленная реплика ищет запись о подключающемся экземпляре в своем спейсе _cluster. Если такой записи нет, связь не устанавливается.
    Если есть, связь подтверждается. Удаленная реплика выполняет чтение любой новой информации из своих файлов .snap и .xlog и отправляет новые запросы на локальную реплику.

В итоге: локальная реплика понимает, к какому набору реплик относится; удаленная реплика понимает, что локальная реплика входит в набор реплик; у двух реплик одинаковое содержимое базы данных.

#4. Если есть файл снимка и указан источник репликации:
Сначала локальная реплика проходит процесс восстановления, описанный в предыдущем разделе, используя свои собственные файлы .snap и .xlog. Затем она отправляет запрос подписки всем репликам в наборе реплик. Запрос подписки содержит векторные часы сервера. Векторные часы включают набор пар „идентификатор сервера, LSN“ для каждой реплики в системном спейсе _cluster. Каждая удаленная реплика, получив запрос подписки, выполняет чтение запросов из файла .xlog и отправляет их на локальную реплику, если LSN из запроса файла .xlog больше, чем LSN векторных часов из запроса подписки. После того, как все реплики из набора реплик отправили ответ на запрос подписки локальной реплики, запуск реплики завершен.

Следующие временные ограничения применимы к версиям 1.7 and 2.1:

  • URI в параметре replication должны быть указаны в одинаковом порядке на всех репликах. Это необязательно, но помогает соблюдать консистентность.
  • Максимальное количество записей в спейсе _cluster — 32. Кортежи для устаревших реплик не переиспользуются автоматически, поэтому по достижении предела в 32 реплики может понадобиться реорганизация спейса _cluster вручную.