|
Planet MySQL
|
Planet MySQL - http://www.planetmysql.org/
|
-
MyQuery 3.3.1 releases - Fixes MyQuery 3.3.0 platform issues
I have released MyQuery 3.3.1 now. This is a minor release in many ways, but still significant in others. MyQuery 3.3.0 had issues on platforms where the runtime library I used wasn't installed. Also, there was a minor (but crashing) bug that caused Ndb Monitor to fail. All this, and a few other minor things, are fixed now.I will eventually blog a bit more on the new features in MyQuery 3.3, such as the plugins, the InnoDB Lock monitor and how to easily define your own monitor dialogs with a simple SELECT statement.Til then, download MyQuery 3.3 from Sourceforge.Cheers/KarlssonAnd by the way, I'm sorry that I failed some QA with version 3.3.0, but it's just me coding away here, and I have a limited amount of machines and above all, time.
-
Oracle Certified MySQL Certifications
I may no longer be in charge of MySQL Certification but it does not mean I am not looking out for those of us with those certs. I am still moderating the MySQL Certified Professionals Group on LinkedIn and running the North Texas MySQL USers Group. But I missed Oracle University re-branding the Sun certifications as Oracle certifications earlier this month. This includes the MySQL certifications that were re-branded as Sun. And for those wanting to take the certification exams, they retain the Prometric numbers set up by Sun. But you will find them listed as:310-810 - Oracle Certified MySQL 5.0 Database Administrator Part 1 310-811 - Oracle Certified MySQL 5.0 Database Administrator Part 2 310-812 - Oracle Certified MySQL 5.0 Developer Part 1310-813 - Oracle Certified MySQL 5.0 Developer Part 2310-815 - Oracle Certified MySQL 5.1 Cluster Database Administrator310-814 - Oracle Certified MySQL Associate
-
The best MySQL SSL Cipher?
This is more of a question than me sharing knowledge, but I'm testing the effects of MySQL SSL on replication delay. Interestingly, my tests show faster replication when I enable SSL, versus disable. The slave_compressed_protocol has an effect too, and I get the best result when I use SSL and slave compression in a non-CPU bound test.
The question came up, however, of what SSL Cipher I'm using. I'm not specifying one in my CHANGE MASTER statement, so I'm guessing I'm getting the same default cipher as if I connect with the regular mysql command line client with SSL, which is:
read more
-
Easy MySQL: transaction isolation and ACID, the simple explanation
Clients often ask what the differences are between the various InnoDB isolation levels, or what ACID means. Here are some simple explanations for those that have not yet read the manual and committed it to memory.
READ UNCOMMITTED
Every select operates without locks so you don’t get consistency and might have dirt reads, which are potentially earlier versions of data. So, no ACID support here.
READ COMMITTED
Has consistent reads without locks. Each consistent read, even within the same transaction, sets and reads its own fresh snapshot.
REPEATABLE READ
The InnoDB default isolation level for ACID compliance. All reads within the same transaction will be consistent between each other – ie, the C in ACID. All writes will be durable, etc etc.
SERIALIZABLE
Same as REPEATABLE READ but MySQL converts regular select statements with preface of LOCK IN SHARED MODE when autocommit is enabled. If it’s disabled then each select is started in a separate transaction which will always make sure that reads are consistent. It also, uh, allows for XA distributed transactions support. You have to be using SERIALIZABLE to correctly use XA transactions.
===========================================================================
ATOMICITY
All transactions fail or no transactions fail. Basically that if a transaction fails because of a hardware issue, connection issue, etc – that partial changes won’t commit. It’s 100% or 0% operation.
CONSISTENCY
Data being read by a select is all at the same state. So when you use a transaction you’re getting the most current and consistent data available. This is related to MVCC (multi version concurrency control)
ISOLATION
Nothing that’s being read is actively being changed by another transaction. Your connection or transaction’s read is not going to be changed by another transaction while you’re dealing with that data.
DURABILITY
Changes to the database persist – basically that means that if a transaction is committed and the DB fails or server crashes your changes will be there – which is why innodb uses transaction log files (where data is kept before being written to disk. The engine will read the logs on next startup and commit any remaining transactions in the logs that did not make to disk based tables.)
-
Three wishes for a new year
It’s a new year by Jewish calendar (and, incidently, today is the first day of the next 365 days). And what do I wish for in the following year?
World peace
Good health to all
Support for ORDER BY & LIMIT in MySQL multi-table UPDATE and DELETE statements, This is sometimes a real show stopper!
Have a good year / next 12 months everyone!
|
News Feeds 
