Read the original article at Don’t Miss Percona Live 2013
The biggest event on the MySQL calendar is the yearly Percona Live and it’s just around the corner. This year you’ll be able to pick from a whopping 110 technical sessions by 90 different speakers from companies like Facebook, Amazon, Google and Linkedin. Learn what’s happening at the cutting edge of open source database deployments. [...]
For more articles like these go to Sean Hull's Scalable Startups
Related posts:
[Read more]
When connecting to MySQL, or executing a query, proper error
handling is required. Many take this very seriously, and do a
construct like mysql_connect() or die() or the
equivalent with mysql_query(). For web apps this
generally makes error codes end up on the user page, you can
easily see this by doing a Google search for some of the common
error texts. Slightly improved apps are nicer to the user and log
the error separately.
But both approaches fail, fundamentally, as they don't take into
account that not all errors are the same and, most importantly,
many error are not fatal but require other forms of action. So
let's look at that, look at what causes the errors so you truly
understand that it's not fatal stuff, and how you can handle
them.
When you get a "not successful" response back from a MySQL API
function, you first need find out what the error is with
mysql_errno() (and …