MySQL CEO Marten Mickos has spoken before about how he is more interested in learning from the successes of Ikea, Ryanair and Virgin Mobile than he is the established proprietary software vendors. Even so, it was surprising to see that Red Hat has looked outside the software industry for its new president and CEO.
Jim Whitehurst was most recently chief operating officer at Delta, where he had responsibility for operations, sales …
[Read more]
The user has session data in memcached. It is set to expire after
X period of time.
How do you update the database to know when the expiration
happened?
Poll for the data.
When you create the session data add a "session_active" field to
the account. If you create a session for the user set this to
"on", otherwise default it to off.
Now insert the data into memcached and set an expire on it. Each
time you fetch the data, touch it to last a bit longer.
How do you turn off the enum "session_active" in MySQL?
Write an Event in 5.1 and probe Memcached via UDF to find out if
the data still exists. If it does not, update the field. Just
select each row that showed an active session and check it.
I got asked this in IRC and had to think about the logic of this.
I am not sure I would design a need into knowing if a session
variable still existed or not, …
A
I'm a big fan of OpenID. However, pretty much all of my past uses
of it have been experiments, demonstrations, or because I sought
out OpenID enabled sites.
A couple of days ago, I finally used it "for real".
A client of MySQL's uses a system called projectpath.com. And
when I first went to it, I saw that it is OpenID enabled!
It's kind of a pity that MySQL.com isn't an OpenID provider for
it's staff, like Sun.com does, so that I could have used
something like "http://openid.mysql.com/mark.atwood" for it.
Instead I just used my personal OpenID of "http://mark.atwood.name/".
I’ve written before about how to figure out which connection is holding the InnoDB locks for which other connections are waiting. In other words, how to figure out who’s blocking you from getting work done when you get InnoDB lock timeouts or other InnoDB lock contention. The short and sweet: turn on the InnoDB lock monitor and use innotop to look at the locks held and waited-for. The InnoDB lock monitor has a few major disadvantages, though:
We just unleashed version 5.0.11 Beta of MySQL Workbench. We fixed the nasty bug, that prevented us from releasing .11 earlier. To find out what’s new take a look at this page (You can trace all changes in detail here).
Although the filenames say 5.0.11a (notice the trailing ‘a’), what’s actually inside the packages is our official 5.0.11 beta release. That’s because we had already uploaded the files to our mirrors when we found that index-related bug on monday - so the fastest way for this release was, to add the suffix.
Please fetch the new release right away and keep up your good work with testing and reporting bugs.
The 2008 MySQL Conference & Expo registration is opened!
Time flies. We’re already at our sixth Users Conference! Looking at the announcement:
Co-presented by MySQL AB and O’Reilly Media, the conference will take place April 14-17, 2008, in Santa Clara, California. The event is expected to bring together over 1,600 open source and database users from some of the most exciting and fastest-growing companies in the world, as well as from the large and active MySQL Community. The program for 2008 will include keynote presentations by Jacek Becla of Stanford Linear Accelerator and MySQL CEO Marten Mickos.
Jay Pipes, our Program Chair, has lead a huge effort in identifying the best out of the near-300 proposals for sessions. …
[Read more]A common question you hear from proprietary vendors when dismissing open source alternatives is “how many customers actually want access to the code anyway?” It is a question I put to an open source software vendor myself earlier this week while playing devil’s advocate.
The response - that the right to modify the source code is more important than actually doing it - is well known, but it is worth repeating in the light of recent events surrounding the Mindquarry open source collaboration project.
“It is strategically important for the customer that the source code is available, even if they don’t want to modify it,” was the response from the open source vendor I was talking to. There are a number of reasons for this:
In MySQL 4.1 and above the longest part of recovery after crash
for Innodb tables could be UNDO stage - it was happening in
foreground and was basically unbound - if you have large enough
transaction which needed to be undone this could take long
hours.
REDO stage on other hand always could be regulated by size of
your Innodb log files so you could have it as large as you like.
Read more about it here.
Since MySQL 5.0 the UNDO stage is running in background so it still can be the longest but would not keep server completely unusable (some limitations still apply though).
In the case I've been working on recently none of these parts was
the longest one.
The server had about 65000 tables using
innodb_file_per_table so "InnoDB: Reading
tablespace information from the .ibd …
mysql_connect() function in PHP's MySQL interface (which for reference maps to mysql_real_connect() function in MySQL C API) has a $client_flags parameter since PHP 4.3.0. This parameter is barely known and almost always overlooked but in some cases it could provide a nice boost to your application.
There's a number of different flags that can be used. We're interested in a specific one, MYSQL_CLIENT_COMPRESS. This flag tells the client application to enable compression in the network protocol when talking to mysqld. It reduces network traffic but at the cost of some CPU time: server has to compress the data and client has to decompress it. So there's little sense in using it if your Web application is on the same host as the database.
When the database is on a dedicated server then compression essentially means trading CPU time (on both server and client) for network time. …
[Read more]