What happens if you wrap your entire process inside of an explicit transaction, e.g. start transaction; create temporary table; populate it using various methods; further manipulate the data; use the data to update a real table; commit;

If your slave crashes for some reason or another during the middle of this transaction, will it roll back correctly; and more importantly, when you restart the slave, where will it pick up?

I’m looking at this from a difficult angle because I want to “manufacture” a result set inside of a stored procedure. The answer I keep getting as a replacement for Oracle’s varray is “use a temp table” and because I’m using replication I’m now looking at a work-around for a a work-around.

create temporary table temp_prefix.foo as
   select * from main_db.bar;

insert into main_db.fizzle
   select * from temp_prefix.foo;

and force the scripts to use the TEMP_PREFIX you specify?

e

The situation I had occur frequently on one install (still a mystery to this day) was the server had a forum using InnoDB tables and it had some index table that liked to corrupt. Ppl were always on this forum and thus always accessing the index so whenever it corrupted (which was about once a week), the server rarely got it’s connection count over 2.

My “solution” was to ditch all the transactional code (only a handful of changes) and change all the tables to MyISAM.

I still feel that I’m missing your point though. Are you saying that my program might connect to the server, get connection ID 1, create table_1, and then there’s a crash? And then that another program would also get connection ID 1 and the two programs would conflict?

Just to clarify what I’m using these tables for: it’s things like rolling up large amounts of performance data into summary tables, holding short lists of things to work on (like client numbers), generating reports, etc. Many of these would go to disk anyway because they’d exceed the size limit on in-memory tables. So no, I haven’t seen a performance hit; I’m much happier with the data on disk anyway, where it will survive a crash.

I’m probably just being overly paranoid here from some of the production disasters I’ve seen with MySQL, particularly involving InnoDB and/or replication. When things go bad, they go real bad…and quickly.

Have you seen a performance hit using this scheme though? I wouldn’t want to writing to disk for temp tables.

The changes I’m referring to are row-based replication, which you can read about in the manual.

I partially disagree with some of your points. However, I can see your point of view, and I strongly agree with your view that fixing problems in replication is better than using workarounds.

Some notes:

Queries to corrupted InnoDB tables don’t always crash MySQL. It depends on the corruption.

I’m not sure exactly what you mean by “have the id of 1… major problems.” I think you mean “crash, write to the same table again, crash, ad infinitum.” However, this won’t be a problem with the way I’m advocating using the tables. They are truly meant to be temporary and used only by one connection, so I do something like “drop table if exists foo_1, create table foo_1(a int), … drop table if exists foo1.” Dropping the table before using it should avoid the problems I think you’re worried about.

Finally, an add-on to the original article. I now add both the connection’s ID and the server’s ID to the table name. This way it’s easy to know whether the table was created on the server I’m looking at (in case I’m looking at a slave). So my tables are now named like this: foo_21_198282. This is also integrated into mk-find (in Maatkit).