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
