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

Master-Master

#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 rest n-1 instances.

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

Monitor synchronization status

Information returned by the info command

ssdb 127.0.0.1:8899> infobinlogs    capacity : 10000000    min_seq  : 1    max_seq  : 74replication    client 127.0.0.1:55479        type     : sync        status   : SYNC        last_seq : 74replication    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: The maximum binlog sequence number in the current 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.