Reputation
11,093
Top tag
Next privilege 15,000 Rep.
Protect questions
Badges
1 12 30
Newest
 innodb
Impact
~640k people reached

Mar
6
comment Problem moving database to new server
First step... Inside query browser, run the query SHOW GRANTS; to be certain you have actually connected with the credentials you used at the login dialog, and that you have the permissions you expect to have.
Mar
4
comment what will happen to the binary log if it reaches its maximum value ? Does it reset to mysql-bin.00001 again?
It will continue growing past 6 digits and will not throw an error until mysql-bin.2147483647 is reached... over two billion binlogs.
Mar
3
answered what will happen to the binary log if it reaches its maximum value ? Does it reset to mysql-bin.00001 again?
Mar
3
comment Prevent Reconnections During Application Cluster Restart
Have you considered the possibility of increasing the thread_cache_size in the MySQL server? If the overhead is really related to a large number of reconnects in a short time, that should help.
Feb
21
answered If all tables are myisam, should I use myisam engine instead of default innodb?
Feb
21
comment If all tables are myisam, should I use myisam engine instead of default innodb?
Changing the storage engine of tables in the mysql schema is generally unsupported and should not be attempted.
Feb
19
comment SELECT RELEASE_LOCK causing “Mysql has gone away”
@MatthewHaworth did you take anything away from the comment above? What is happening in the time right before the error? Is the server sending data, or just processing data internally (stored procedure), or...? If you issue another query immediately before you release the lock (e.g. SELECT NOW():) what happens?
Feb
18
comment SELECT RELEASE_LOCK causing “Mysql has gone away”
@MatthewHaworth comically, I ran into a ERROR 2013 (HY000): Lost connection to MySQL server during query this morning. In this case, the connection wasn't strictly idle -- the server was trying to send data and the application wasn't ready. When the net_write_timeout timer expires before the client is ready to read, the server drops the connection and this error results when the client is ready. If you're supposed to be reading from the server, and you keep it waiting too long, the symptom is the same. Is that the case, here, or is the connection idle?
Feb
18
comment SELECT RELEASE_LOCK causing “Mysql has gone away”
Here's a command line one-liner: perl -e '$|=1; $i = 0; while (1) { warn "sending query..."; print "SELECT $i,NOW(),CONNECTION_ID();\n"; sleep 1; $i += 60; warn "wait $i seconds...\n"; sleep $i-1; }' | mysql --table --host={hostname} --user={username} --password={password} ... at some point, I'd expect an infinite timeout or "MySQL server has gone away" followed by the displayed connection_id changing since the command line client should try to reconnect.
Feb
18
comment SELECT RELEASE_LOCK causing “Mysql has gone away”
@MatthewHaworth I'm skeptical: the hosting provider's assertion doesn't mean much to me... not only because I'm jaded from experience and don't trust vendors :) but also because in a stateful firewall, timeouts often do not need to be configured. They are there, enabled, often silently and by default. In cheaper hardware, they are there and can't be configured. If this were my issue, I would be attempting to prove or disprove that it is a timeout.
Feb
17
answered SELECT RELEASE_LOCK causing “Mysql has gone away”
Feb
13
comment How to use MySQL stored function argument to refer to column name?
It works, but it shouldn't be done. Objects aren't data and data isn't objects. Crossing that boundary reeks of bad design and introduces potential security vulnerabilities. Try running CALL showUnique('1) UNION ALL SELECT user FROM mysql.user); #');, for example.
Feb
13
comment InnoDB Deadlocks Involving Currency Transactions
Ah, but if I'm reading the deadlocks correctly, you had 23093 row locks and a lock on the primary key all held by trx 2, which suggested a full table scan was being done to find the rows to update, in the absence of that index. Adding that index should result in a lot fewer rows being locked when that "session_lastclick" query runs, reducing the chance of a deadlock. Arguably, there's no need to do that second query, since the value of session_lastclick subtracted from the current time could give you a true/false answer to whether a session is "active" whenever you need to know.
Feb
12
comment InnoDB Deadlocks Involving Currency Transactions
Is there an index on session_lastclick?
Feb
12
comment How to evolve MySQL schema while maintaining integrity
"It will even unlock it even if you had manually locked it." -- this should only be true if the OS is Windows and the table is transactional. Have you considered SET GLOBAL READ_ONLY = 1;...?
Feb
12
awarded  Enlightened
Feb
12
awarded  Nice Answer
Feb
11
comment mysqlslow - excluding queries from mysqldump
heh... it looks like it would actually be something along the lines of -g '(?{{ undef $_ if \/SQL_NO_CACHE\/ }})' ... now, I'm curious. Negative matching doesn't seem to be natively supported, but it "should" be possible (famous last words).
Feb
10
comment MYSQL: InnoDB inserts wont rollback transaction inside a stored procedure
So, something else is either committing or rolling back your transaction. You are calling EXECUTE on 5 different prepared statements, but what those contain is not shown here. It should be one of those that's doing it. (Unfortunately, ROLLBACK; and COMMIT; are both accepted by MySQL without raising an exception, when you don't actually have a transaction running; the ROLLBACK TO SAVEPOINT hack doesn't silently fail like the others, and hence the reason this test works.)
Feb
10
comment MYSQL: InnoDB inserts wont rollback transaction inside a stored procedure
I agree it isn't obvious why this wouldn't work. Right before IF @Canceled = 1 THEN try adding SAVEPOINT foo; ROLLBACK TO SAVEPOINT foo;. The net effect of this should be no change in behavior -- however, it will throw an exception if you are, for whatever reason, not actually inside a transaction at that point, which seems like the most likely explanation, even though it's not obvious from the code shown here why that might be the case.