Thanks for the information. I to found a work around-a much uglier approach.
For all ALTERs of a src table to work when synonyms of tables are present: perform the ALTER on the slave itself and add to skip-slave-errors=1060 This is a quick work around. Very very ugly. - Dathan Vance Pattishall - Sr. Programmer and mySQL DBA for FriendFinder Inc. - http://friendfinder.com/go/p40688 -->-----Original Message----- -->From: Guilhem Bichot [mailto:[EMAIL PROTECTED] -->Sent: Tuesday, October 28, 2003 3:32 AM -->To: Dathan Vance Pattishall -->Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; -->[EMAIL PROTECTED] -->Subject: RE: reproducible error 17 --> -->On Tue, 2003-10-28 at 12:07, Guilhem Bichot wrote: -->> On Tue, 2003-10-28 at 00:15, Guilhem Bichot wrote: -->> > On Mon, 2003-10-27 at 22:01, Dathan Vance Pattishall wrote: -->> -->> > So the conclusion is: unfortunately, the symlink support in MySQL was -->> > not designed for "synonyming", as far as DDL (Data Definition -->Language - -->> > CREATE TABLE / DROP TABLE / ALTER TABLE) commands are concerned. It -->was -->> > designed with the thought that symlinks are to be used to point to a -->> > *different* directory (another partition where there is more room, or -->> > another device to balance disk load). For DDL commands MySQL always -->> > expects a table to exist only once, i.e. to have only one name. -->Putting, -->> > in the database directory, a symlink and the real table means giving -->2 -->> > names to one table... -->> > -->> > I will add a note about this into our manual soon. I understand this -->is -->> > is an inconvenience for you; you will be safe if you always do the -->DDL -->> > commands (ALTER TABLE, in your case) on the real table. It's ok to do -->> > DML commands (INSERT/DELETE/UPDATE/LOADDATA, which fortunately occur -->> > much more often than ALTER TABLE normally) on both tables -->indifferently. -->> -->> Sorry, I should have been more accurate in the last sentence. -->> It's ok to do DML commands *always* on the real table OR *always* on -->the -->> synonym table. -->> If thread1 uses the real table's name, and thread 2 uses the synonym, -->> the query cache can be fooled: -->> - set global query_cache_size=1000000; -->> - connection1: select * from tbl_; -->> - connection2: insert into tbl values(1); -->> - connection1: select * from tbl_; you don't see the inserted row! -->> - connection1: flush tables (empties caches); select * from tbl_; you -->> see the inserted row! -->> -->> Even if you disable the query cache, I am not sure if it's safe to use -->> both names; there could be some other fooled caches in MySQL. -->> -->> Simply put, things go wild when the real name and the synonym are both -->> used. Which impacts the interest of using synonyms (hum). And FLUSH -->> TABLES is a remedy. -->> -->> I'll add this to the manual. --> -->Added. You should be able to see it in our online manual -->www.mysql.com/doc -->(end of section "Using symbolic links") in the next hours. --> --> -->-- -->MySQL General Mailing List -->For list archives: http://lists.mysql.com/mysql -->To unsubscribe: -->http://lists.mysql.com/[EMAIL PROTECTED] -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
