Версия:

Руководство пользователя / Репликация / Мониторинг набора реплик
Руководство пользователя / Репликация / Мониторинг набора реплик

Мониторинг набора реплик

Мониторинг набора реплик

To learn what instances belong in the replica set, and obtain statistics for all these instances, issue a box.info.replication request:

tarantool> box.info.replication
      ---
        replication:
          1:
            id: 1
            uuid: b8a7db60-745f-41b3-bf68-5fcce7a1e019
            lsn: 88
          2:
            id: 2
            uuid: cd3c7da2-a638-4c5d-ae63-e7767c3a6896
            lsn: 31
            upstream:
              status: follow
              idle: 43.187747001648
              peer: replicator@192.168.0.102:3301
              lag: 0
            downstream:
           vclock: {1: 31}
          3:
            id: 3
            uuid: e38ef895-5804-43b9-81ac-9f2cd872b9c4
            lsn: 54
            upstream:
              status: follow
              idle: 43.187621831894
              peer: replicator@192.168.0.103:3301
              lag: 2
            downstream:
              vclock: {1: 54}
      ...

Данный отчет сгенерирован для набора реплик из трех экземпляров с конфигурацией мастер-мастер, у каждого из которых есть свой собственный ID экземпляра, UUID и номер записи в журнале.

../../../_images/mm-3m-mesh.svg

Запрос был выполнен с мастера №1, и ответ включает в себя статистику по двум другим мастерам относительно мастера №1.

Основные индикаторы работоспособности репликации:

  • бездействие, время (в секундах) с момента получения последнего события от мастера.

    A replica sends heartbeat messages to the master every second, and the master is programmed to reconnect automatically if it does not see heartbeat messages within replication_timeout seconds.

    Therefore, in a healthy replication setup, idle should never exceed replication_timeout: if it does, either the replication is lagging seriously behind, because the master is running ahead of the replica, or the network link between the instances is down.

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

    Since the lag calculation uses the operating system clocks from two different machines, do not be surprised if it’s negative: a time drift may lead to the remote master clock being consistently behind the local instance’s clock.

    For multi-master configurations, lag is the maximal lag.