Revisiting the replacement of auto incrementing unique_id's with GUID, global unique id's. Based on thread from Sept 2004.
This update will allow DBMail to handle multiple servers setup for failover, without the danger of ever having duplicate ID's.
In looking at the system, it seems that this is the last thing holding DBMail back from a complete failover system using MySQL replication. As it stands now it could be possible for duplicate ID's if one machine failed in a master/slave DBMail configuration.
Contrary to earlier thoughts this would be consistent with the RFC. This is due to the fact that the RFC does not require “increment-only” id's as defined in the current DBMail implemenation. The unique_id's detailed in the below “RFC Overview” can be guid's, they must be unique and ascending, but do not have to be sequential.
Example: (1,5,6,8,40,1000…) not (1,2,3,4,5,6,7…)
The below are links to previous threads that will get us up to speed on this.
Would it be possible for this to be listed somewhere in the development plan? I know there is a lot of interest from both DBMail and Cyrus Users.