On Mon, Dec 30, 2002 at 10:16:07PM -0600, Dan Nelson wrote: > Bah. sql, query, queries, smallint > > In the last episode (Dec 30), Rick Faircloth said: > > Aaaahhhh, that's how the auto_increment id problem is solved. > > > > I wonder why they can't do something like Access with its > > ReplicationID or whatever it's called... > > Access just used a random 32-bit integer, and you risked generating > dupes. If you go this route it might be better to create a dual-column > primary key, with the first column being the server-id taken from > my.cnf (already visible in the @server_id variable), and the other > column being a standard AUTO_INCREMENT field (but with each server > keeping track of its own max ID).
Yeah, that's another option we tossed around. It has some not so obvious implications for the replication code, but it's doable. It'd require chaning the binlog format, though. Like AUTO-INCREMENTs today, the slaves would need to use the server-id of the server that wrote the binlog entry, not necessarily the one that provided the binlog data (think of multi-level replication with a slave of a slave). Jeremy -- Jeremy D. Zawodny | Perl, Web, MySQL, Linux Magazine, Yahoo! <[EMAIL PROTECTED]> | http://jeremy.zawodny.com/ MySQL 3.23.51: up 15 days, processed 562,721,968 queries (407/sec. avg) --------------------------------------------------------------------- Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
