Configuration and monitoring of SSDB master-slave synchronization and replication


Configuration

For old versions, you must specify the IP address of the master through slaveof.ip, but for new versions (1.9.2) , you can specify the host name (domain name) of the master through slaveof.host.

Master-Slave

server 1

replication:
    slaveof:

#server 2

replication:
    slaveof:
        id: svc_1

    # sync|mirror, default is sync
    type: sync
    # use ip for older version
    #ip: 127.0.0.1
    # use host since 1.9.2
    host: localhost
    port: 8888

主-主

#server 1

replication:
    slaveof:
        id: svc_2

    # sync|mirror, default is sync
    type: mirror
    # use ip for older version
    #ip: 127.0.0.1
    # use host since 1.9.2
    host: localhost
    port: 8889

#server 2

replication:
    slaveof:
        id: svc_1

    # sync|mirror, default is sync
    type: mirror
    # use ip for older version
    #ip: 127.0.0.1
    # use host since 1.9.2
    host: localhost
    port: 8888

Multi-master

In a group of SSDB instance groups containing a total of n instances, each instance must slaveof the remaining n-1 Example.

replication:
    slaveof:
        id: svc_1

    # sync|mirror, default is sync
    type: mirror
    # use ip for older version
    #ip: 127.0.0.1
    # use host since 1.9.2
    host: localhost
    port: 8888
slaveof:
    id: svc_2
    # sync|mirror, default is sync
    type: mirror
    # use ip for older version
    #ip: 127.0.0.1
    # use host since 1.9.2
    host: localhost
    port: 8889
# ... more slaveof

Monitoring synchronization status

Information returned by the info command

ssdb 127.0.0.1:8899> info
binlogs
    capacity : 10000000
    min_seq  : 1
    max_seq  : 74
replication
    client 127.0.0.1:55479
        type     : sync
        status   : SYNC
        last_seq : 74
replication
    slaveof 127.0.0.1:8888
        id         : svc_2
        type       : sync
        status     : SYNC
        last_seq   : 10023
        copy_count : 0
        sync_count : 44

binlogs

The write operation status of the current instance.

  • capacity: the maximum length of the binlog queue
  • min_seq: the minimum binlog sequence number in the current queue
  • max_seq: current The maximum binlog sequence number in the queue

replication

There can be multiple replication records. Each record represents a connected slave (client), or a master (slaveof) connected to the current server. ).

  • slaveof|client host:port, the host:port of the remote master/slave.
  • type: type, sync|mirror.
  • status: Current synchronization status, DISCONNECTED|INIT|OUT_OF_SYNC|COPY|SYNC.
  • last_seq: The sequence number of the last binlog sent or received.
  • slaveof.id: The id of the master (this is from the slave's perspective, you never need to configure its own id on the master).
  • slaveof.copy_count: During full synchronization, what has been copied The number of keys.
  • slaveof.sync_count: The number of binlogs sent or received.

About status:

  • DISCONNECTED: The connection with the master is disconnected, usually due to network interruption.
  • INIT: Initialization state.
  • OUT_OF_SYNC: Due to a large number of write operations on the master in a short period of time, resulting in The binlog queue is eliminated, the slave loses the synchronization point, and has to copy all the data again.
  • COPY: During the process of copying the benchmark data, new write operations may not be synchronized in time.
  • SYNC: The synchronization status is healthy.

Determine the synchronization status

For master, binlogs.max_seq refers to the latest one on the current instance The serial number of the write (write/update/delete) operation, replication.client.last_seq refers to the serial number of the latest binlog sent to the slave.

So, if you want to determine the master Whether the slave synchronization has been synchronized (real-time update), then determine whether binlogs.max_seq and replication.client.last_seq are equal.