Tokyo cabinet & tyrant multi-server node master-master deployment

Tokyo cabinet & tyrant supports master-slaver and master-master distributed deployment. However, because master-slaver needs to manually set the master after the master is down, this method of Cold Start is not very good. In addition, the master-slaver method is basically used to process multi-read and write operations. For projects with a low read/write ratio, it is more suitable for the master-master mode.

Assume that two machines are distributed master servers named TT1 and TT2, And the IP addresses are 10.10.13.11 and 10.10.13.12.

After installing TC and TT, run ttserver directly. The script is:

TT1: ShellCode

1. Mkdir ulog
2. Ttserver-Port1977-Ulog-Sid1-Mhost10.10.13.12-Mport1978-RTS1. Rts casket-1. Tch

 
Mkdir ulogttserver-port 1977-ulog-Sid 1-mhost 10.10.13.12-mport 1978-RTS 1.rts casket-1.tch
 

TT2: shell code

1. Mkdir ulog
2. Ttserver-Port1978-Ulog-Sid2-Mhost10.10.13.11-Mport1977-RTS2. Rts casket-2. Tch

 
Mkdir ulogttserver-port 1978-ulog-Sid 2-mhost 10.10.13.11-mport 1977-RTS 2.rts casket-2.tch
 

After startup, logs are displayed as Log Code

2. 2010-06-02t10:12:11+08:00Info connected:10.10.13.12:60330
4. 2010-06-02t10:12:11+08:00Info doing repl command
6. 2010 - 06 -02t10: 12 : 11 + 08 : 00 info replicating to SID = 2 after 1275379364260424
8. 2010 - 06 -02t10: 12 : 12 + 08 : 00 info replicating from SID = 2 ( 10.10 . 13.11 : 1977 ) 1275443629795059

2010-06-02t10: 12: 11 + 08: 00 info connected: 10.10.13.12: 603302010-06-02t10: 12: 11 + 08: 00 info doing repl command2010-06-02T10: 12: 11 + 08: 00 info replicating to SID = 2 after 127520.36000000002010-06-02t10: 12: 12 + 08: 00 info replicating from SID = 2 (10.10.13.11: 1977) after 1275443629795059
 

After the master-master mode is started, the ttserver in master-master mode can run. According to the automatic replication policy of TT, data written to TT1 will be copied to TT2, and vice versa.

For more information about the parameters, see http://1978th.net/tokyotyrant/spex.html: TT.

1. -ulog path: Specify the Update log directory.
2. -Sid num: Specify the server ID.
3. -mhost name: Specify the Host Name of the replication master server.
4. -mport num: Specify the port number of the replication master server.
5. -RTS path: Specify the replication time stamp file.
6. ". tch " , the database will be a hash database.

-Ulog path: Specify the Update log directory. -Sid num: Specify the server ID. -mhost name: Specify the Host Name of the replication master server. -mport num: Specify the port number of the replication master server. -RTS path: Specify the replication time stamp file. ". tch ", the database will be a hash database.
 

It should be noted that, if TT1 goes down and the persistent file casket-1.tch is lost, there may be a problem that data cannot be synchronized from TT2 after restart, because the time stamp of RTS is too large, modify 1. if the value in RTS is 0, all data is obtained from tt2. When a newly added node is created for the first time, the default value in the RTS is 0, so all data is synchronized.

There are not many introductions about ttmaster-master. They only find the dual-host master, and the replication between them is a master-slaver replication method. In addition, a single node can only be used as a master-slaver with one node. In this way, data can only be replicated cyclically at the moment. If one node breaks down, data may expire. Robbin is right. TT & TC does not exist as a distributed database.

Based on the TT, master-slaver, and master-master modes, the dual-host MySQL can be used as the master, and then the slaver mode is mounted after each master without additional code.

When running as a server, you still need to add some additional parameters, such as the compression of persistent files. Some colleagues found that the file size has been increasing during the test, the added Compression Parameters are improved.