Welcome to Log Buffer, the weekly roundup of database blogs.
Welcome to Log Buffer, the weekly roundup of database blogs. We’re back this week with a short Log Buffer #190. Only ten more issues, and we’ll be celebrating our 200th edition post.
The MySQL track at Kaleidoscope in Washington, DC during June 28-July 1st is set! Here is the schedule, Lincoln VI is the MySQL track room. It’s not too late to register for Kaleidoscope – be sure to use the discount code MYSQL to save $300 off your registration (assuming you are not a member of ODTUG).
Welcome to Log Buffer, a weekly review of the database industry. This week’s issue Log Buffer #189 is generously published by Iggy Fernandez, editor of the quarterly journal of the Northern California Oracle User Group (NoCOUG).
I have been talking with a group of folks who have been making a product that has lots of free functionality, including the ability to centrally manage many MySQL instances. The administration functions include starting and stopping MySQL, seeing status and system variables, seeing and managing the MySQL config file (/etc/my.cnf), seeing and managing accounts, a small dashboard of overall health graphs, and more.
A user group member mentioned PuTTY Connection Manager. It wraps around PuTTY and gets the existing saved connections, makes a nicely tabbed browsing window where you can open sessions by double-clicking the connections, which are now listed on the right-hand side.
Even though all of us DBAs come from a wide variety of cultures, I’m willing to bet that every one of us had to work his way through a multiple choice test. If you ever took an Oracle certification exam, you know what I mean.
This article will explain why changing the sort_buffer_size kills performance and stability, it will also talk more about understanding why, an integral part against the “Battle against any guess.” Baron’s recommendation to leave sort_buffer_size as the default is just as bad as all the advice given to change the sort_buffer_size, because all that advice (including Baron’s) does not explain the underlying causes.
I have a hard time trying to figure out the deeper meaning behind Peter’s post, given that Percona writes a storage engine for MySQL, XtraDB. Does this mean that Percona will stop developing XtraDB? Does this mean that the Percona Server will diverge farther and farther away from MySQL so that they’re not compatible any more and migrating from MySQL to Percona Server is very difficult?
It’s Friday already, and we know what that means! Log Buffer, the industry’s weekly review of database blogs is here again for your reading pleasure in the 188th issue.