RE: reproducible error 17

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 Bugs Mailing List
For list archives: http://lists.mysql.com/bugs
To unsubscribe:    http://lists.mysql.com/[email protected]