My fellow MySQLers who I have chatted with recently on IRC, know
how much the AUTO-INC table lock in MySQL has been bugging me.
Whenever my server gets an increased number of concurrent
INSERTs, I start experiencing thrashing.
Yesterday night I spent all night trying to find the bottleneck
within my system which happened to be none other than disk
bound.
Everyone knows that InnoDB is excellent for its concurrency,
thanks to its row level lock granularity. What comes as a
surprise, to some, is that if you happen to use an AUTO INCREMENT
column, then InnoDB needs to acquire a special, table level,
AUTO-INC lock.
Everything was fine until I started finding many threads in
InnoDB queue waiting to acquire this lock.
iostat -xnz 5 reported disk busy at 100% most of the times.
…
Recently, I found out that I'll be speaking at the upcoming MySQL Conference in Santa Clara, California. Last year, it was a lot of fun and the conference was very successful. I can't wait to see everyone there again.
A couple of weeks ago I submitted a request to open a new project on Sourceforge for the innotop MySQL and InnoDB monitor. I want to make it easier for others to collaborate, especially package maintainers. Yesterday I got word of its approval. I have done a quick-and-dirty import of the source code into its new home, and I'm now continuing work on the next major version, which I've been working on for about six weeks. This post is about Sourceforge, what I've gotten done, and also to ask for your help.
One small fact about backup table and restore table that isn’t listed in the manual is that these commands lose the auto increment value if rows at the head of the table are deleted. For example if you have auto increment values of 1,2,3,4 in a table the auto increment value is 5. If you delete row 4 the next auto increment will still be 5. If you backup/restore the table the auto increment will be reset to 4. The auto increment value in myisam is stored in the MYI file. Since this file isn’t backed up myisam restores the auto increment value from the highest existing value in the table. This value may or may not be the actual value of auto increment. As the manual says these commands should not be used. Instead use mysqlhotcopy.
A couple of weeks ago I submitted a request to open a new project on Sourceforge for the innotop MySQL and InnoDB monitor. I want to make it easier for others to collaborate, especially package maintainers. Yesterday I got word of its approval. I have done a quick-and-dirty import of the source code into its new home, and I’m now continuing work on the next major version, which I’ve been working on for about six weeks.
A few weeks ago, nineteen MySQLers had a successful meeting in Berlin. The QA and Build teams invited some guests from other Engineering teams and from Support, and we experimented with a couple of new meeting practices. We’re not yet at Meeting Nirvana, but we felt that we had taken great strides compared to several earlier MySQL Dev Mtgs.
Plenty of literature and blogs exist on arranging good meetings. The scope of this blog article is limited to physical meetings in virtual organisations, i.e. collecting a group of people who work together every day but see each other once or at most twice a year. That special context puts the emphasis on certain decisions and practices, which I attempt at highlighting below.
The twelve items come in a chronological order.
Before, during and after the meeting 1. Set the right meeting goals.
- Try to solve fewer problems than you …
The other day I heard that InnoDB UPDATE statements perform DELETE and INSERTs and REPLACE is therefore more efficient. Now I'm trying to confirm it by finding documentation on it.
Steve Karam, the Oracle Alchemist, has published the 26th edition of Log Buffer, the weekly review of database blogs. I’m always looking for more editors, so if you’d like to present your view of the database blogosphere, please peruse the Log Buffer homepage and get in touch. And now, I give you Log Buffer #26.
MySQL support same-server replication into another database, Its quite a weired requirement, but in reality weired is common.
Consider a server 192.168.5.70, which has 2
databases db1 and db2
Now we shall set up replication for two tables on
db1, ie. table1 and
table2.
Here is the my.cnf
[mysqld] server-id=1 #### Replication #### report-host=master-is-slave-host log-bin=192.168.5.70-binlog relay-log=192.168.5.70-relaylog replicate-same-server-id=1 binlog-do-db=db1 # Note.... On rewrite, the command is changed into buffer # so the replicate-do-db and replicate-do-table should have the # re-written db name. replicate-rewrite-db=db1->db2 replicate-do-table=db2.table1 replicate-do-table=db2.table2
MySQL support same-server replication into another database, Its quite a weired requirement, but in reality weired is common.
Consider a server 192.168.5.70, which has 2
databases db1 and db2
Now we shall set up replication for two tables on
db1, ie. table1 and
table2.
Here is the my.cnf
[mysqld] server-id=1 #### Replication #### report-host=master-is-slave-host log-bin=192.168.5.70-binlog relay-log=192.168.5.70-relaylog replicate-same-server-id=1 binlog-do-db=db1 # Note.... On rewrite, the command is changed into buffer # so the replicate-do-db and replicate-do-table should have the # re-written db name. replicate-rewrite-db=db1->db2 replicate-do-table=db2.table1 replicate-do-table=db2.table2