Great!
This is exactly the concept we discussed in the thread
last year. Although we talked about more detail, I think
that this will be sufficiently unique to avoid collisions.
My only suggestion would be that the code to generate the
GUID be kept in a function that can my easily modified
system-wide. This will allow for updates later if we find
the GUID needs to be slightly different to maintain
uniqueness. I'm guessing you've already done that.
Thanks for jumping on this... I've started a couple times
but am really a Java developer and not too familiar with
the DBMail code.
I think this will be a great addition to the system.
Scalable multi-master mailserver with no message id
collisions!!!
Kevin Baker
> Ok.
>
> I've committed some initial code to svn. Next step will be
> to actually
> replace auto_increment columns with the new bigint kind
> and fix all the
> places where "INSERT INTO" is used.
>
>
> Paul J Stevens wrote:
>> I've been reading back some of the mail related to this
>> issue.
>>
>> I think I'll use the following to generate guids.
>>
>> gettimeofday (2) will yield the unixtime, plus
>> microsecs. Combined with
>> a server id we get:
>>
>> u64_t get_guid(int serverid)
>> {
>> char guidstr[30];
>> struct timeval tv;
>>
>> if (gettimeofday(&tv,NULL))
>> return 0;
>>
>> snprintf(guidstr,30,"%ld%06ld%02d",
>> tv.tv_sec, tv.tv_usec,serverid);
>>
>> return (u64_t)strtoll(guidstr,NULL,10);
>> }
>>
>> if we then store the server-id in the dbmail.conf (like
>> mysql does), we
>> get (using serverid=1) something like:
>>
>> #> while [ 1 ]; do ./testguid; sleep 1; done
>> 111702774760755001
>> 111702774861137101
>> 111702774961515701
>> 111702775062210101
>>
>> would that be fine-grained enough? I should think so
>> myself.
>>
>> Also, all current auto_increment fields will have to be
>> updated. Now
>> that is no big deal for mysql using alter table
>> statements. Even for
>> postgres that shouldn't be too painful since pgsql
>> already uses bigint
>> and we only have to remove the nextval() from all
>> relevant columns.
>>
>>
>>
>>
>> Kevin Baker wrote:
>>
>>>Very True...
>>>
>>>We discussed the GUID's being generated based on sync'ed
>>>datetime stamp with a unique ID per server. (NTP
>>> required)
>>>
>>>My primary interest now is to create simple 2 machine
>>>clusters for each user segment. Each of the machines in
>>>the cluster would use guid's for unique_id values.
>>>
>>>Each cluster synced through master-master. DNS Round
>>> Robin
>>>for load "balance". Heartbeat for failover.
>>>
>>>This would give loadbalance and failover on commodity
>>>hardware. With guid unique_id's there would be no id
>>>collision so it should failover and sync well.
>>>
>>>
>>>
>>>Kevin
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>>Kevin Baker wrote:
>>>>
>>>>
>>>>
>>>>>I was hoping to peak some new interest in using GUID's
>>>>>in
>>>>>place of the incrementing unique_id's in the current
>>>>>code
>>>>>base.
>>>>>
>>>>>This would be the key to non-colliding id's for a
>>>>>loadbalanced/failover system on a master-master mysql.
>>>>
>>>>Since GUIDs can be generated by the application before
>>>>inserting new records to the database (as opposed to
>>>>reading back an autogenerated nmber after insert), more
>>>>than one DBMail servers could use a single RDBMS
>>>> backend.
>>>>
>>>>This, when viewed in the light of RDBMS clusters would
>>>>make
>>>>a formidable (/w loadbalance + failover) system.
>>>>
>>>>_______________________________________________
>>>>Dbmail-dev mailing list
>>>>[email protected]
>>>>http://twister.fastxs.net/mailman/listinfo/dbmail-dev
>>>>
>>>
>>>
>>>_______________________________________________
>>>Dbmail-dev mailing list
>>>[email protected]
>>>http://twister.fastxs.net/mailman/listinfo/dbmail-dev
>>>
>>
>>
>
> --
> ________________________________________________________________
> Paul Stevens paul
> at nfg.nl
> NET FACILITIES GROUP GPG/PGP:
> 1024D/11F8CD31
> The
> Netherlands________________________________http://www.nfg.nl
> _______________________________________________
> Dbmail-dev mailing list
> [email protected]
> http://twister.fastxs.net/mailman/listinfo/dbmail-dev
>
