In the server configuration file of fastdfs, The bind_addr parameter is used when the local IP address needs to be bound. Only this parameter is related to host features, and other parameters are
It can be configured in a unified manner. To facilitate management and maintenance, it is recommended that the configuration files of all tracker servers be the same as those of all storage
Server configuration files are the same. The configuration file of the tracker server does not contain the storage server
All tracker servers are listed in the server configuration file. This determines the storage server and tracker
The connection between servers is actively initiated by the storage server.
Server starts a thread for connection and communication. For the communication protocols, see section 2. Storage server to Tracker server command in fastdfs howto-protocol. The tracker server saves the storage group and the storage under each group in the memory.
Server, and connect to your own storage
The server and its groups are saved to the file so that the storage information can be directly obtained from the local disk next time the service is restarted. Storage
The server records all servers in the group in the memory and records the server information in the file. Tracker server and storage
The following table lists the storage servers that are synchronized between servers:
1. If a new storage server or storage
When the status of the server changes, the tracker server will synchronize the storage server list to all the storage
Server. Taking the addition of storage server as an example, because the newly added storage server actively connects to Tracker
When a new storage server is added to the group, all the storage
Server returns to the newly added storage server, and returns the list of storage servers in the group to other storage
2. If a new tracker server is added, the storage server connects to the tracker
The tracker server returns a smaller list of storage servers than those recorded on the local machine.
No storage server on the server is synchronized to the tracker server. The storage servers in the same group are peer-to-peer. operations such as file upload and deletion can be performed on any storage
Server. File synchronization only supports storage in the same group.
The source server is synchronized to the target server. Taking file upload as an example, assume that a group has three storage servers
A, B, and C. The file F is uploaded to server B, and B synchronizes the file F to the other two servers A and C. We may wish to upload the file F to server B as the source operation, F file on server B
Is the source data; the operations for synchronizing file F to server A and C are backup operations, and the F files on server A and C are backup data. The synchronization rules are summarized as follows:
1. Only the storage servers in this group are synchronized;
2. The source data needs to be synchronized, And the backup data does not need to be synchronized again; otherwise, a loop is formed;
3. the second rule mentioned above has an exception, that is, when a new storage server is added, an existing storage server transfers all the existing data (including the source data and backup data) synchronize to the new server. The storage server has seven statuses:
# Fdfs_storage_status_init: initialization. The source server that has not yet synchronized existing data
# Fdfs_storage_status_wait_sync: the source server that has synchronized existing data is waiting for synchronization.
# Fdfs_storage_status_syncing: synchronizing
# Fdfs_storage_status_deleted: deleted. This server is removed from this group (note: this status function has not been implemented yet)
# Fdfs_storage_status_offline: offline
# Fdfs_storage_status_online: Online, not yet available
# Fdfs_storage_status_active: online, providing services When the storage server status is fdfs_storage_status_online
When the server initiates a heart beat request to the tracker server, the tracker
The server changes its status to fdfs_storage_status_active. When a new storage server a is added to the group, the system automatically synchronizes existing data. The processing logic is as follows:
1. Storage
Server A connects to the tracker server.
The status of a is set to fdfs_storage_status_init. Storage Server
A. Ask the source server for append synchronization and the end time of append synchronization. If there is only storage server in the group
A. If the number of successfully uploaded files in the group is 0, no data needs to be synchronized.
A can provide online services. At this time, tracker sets its status to fdfs_storage_status_online. Otherwise, tracker
The server sets its status to fdfs_storage_status_wait_sync to proceed with Step 2; 2. Assume that the tracker server is assigned to storage server a to synchronize the source storage of existing data
Server is B. The communication between the storage server and the tracker server in the same group indicates that the storage server is added.
A. the synchronization thread will be started and the tracker server will be asked to append the synchronization source server to storage server a and the end time. Storage
Server B will synchronize all data before the time point to storage server A, while the remaining storage
The server synchronizes the source data to storage server a after the deadline. After the deadline, the storage server
B's synchronization to storage server A will be switched from append synchronization to normal synchronization, only the source data will be synchronized; 3. Storage Server B to storage server
When a synchronizes all the data and no data is to be synchronized, storage server B requests the tracker server
The status of a is set to fdfs_storage_status_online;
4 When storage server a initiates heart beat to the tracker server, the tracker server changes its status to fdfs_storage_status_active.
http://blogold.chinaunix.net/u2/74846/index.html
