|
Planet MySQL
|
Planet MySQL - http://www.planetmysql.org/
|
-
MySQL at DrupalCamp, Goteborg - Sweden
DrupalCamp Conference is hold in Göteborg, Sweden on May 25, 2013.
MySQL is part of this show and I would like to invite you to our session on "Scalability and Availability with MySQL Replication" given by Sven Sandberg on Saturday-May 25, 2013 @ 13:45-14:25!
So, if you are close to Göteborg or attending this event, do not forget to come to listen Sven's talk!
-
Percona XtraBackup 2.1.3 for MySQL available for download
Percona is glad to announce the release of Percona XtraBackup 2.1.3 for MySQL on May 22, 2013. Downloads are available from our download site here and Percona Software Repositories.This release fixes a high priority bug. It’s advised to upgrade your latest 2.1 version to 2.1.3 if you’re using the Percona XtraBackup with Percona XtraDB Cluster. This release is the latest stable release in the 2.1 series.Bug Fixed:Percona XtraBackup 2.1.2 would hang when performing State Snapshot Transfer. Bug fixed #1182698.Release notes with all the bugfixes for Percona XtraBackup 2.1.3 are available in our online documentation. Bugs can be reported on the launchpad bug tracker.* * *Percona XtraBackup is the world’s only open-source, free MySQL hot backup software that performs non-blocking backups for InnoDB and XtraDB databases. With Percona XtraBackup, you can achieve the following benefits:Backups that complete quickly and reliablyUninterrupted transaction processing during backupsSavings on disk space and network bandwidthAutomatic backup verificationHigher uptime due to faster restore timeXtraBackup makes MySQL hot backups for all versions of Percona Server, MySQL, MariaDB, and Drizzle. It performs streaming, compressed, and incremental MySQL backups.Percona’s enterprise-grade commercial MySQL Support contracts include support for XtraBackup. We recommend support for critical production deployments.The post Percona XtraBackup 2.1.3 for MySQL available for download appeared first on MySQL Performance Blog.
-
MySQL vs Drizzle plugin APIs
There’s a big difference in how plugins are treated in MySQL and how they are treated in Drizzle. The MySQL way has been to create a C API in front of the C++-like (I call it C- as it manages to take the worst of both worlds) internal “API”. The Drizzle way is to have plugins be first class citizens and use exactly the same API as if they were inside the server.
This means that MySQL attempts to maintain API stability. This isn’t something worth trying for. Any plugin that isn’t trivial quickly surpasses what is exposed via the C API and has to work around it, or, it’s a storage engine and instead you have this horrible mash of C and C++. The byproduct of this is that no core server features are being re-implemented as plugins. This means the API is being developed in a vacuum devoid of usefulness. At least, this was the case… The authentication plugin API seems to be an exception, and it’s interesting to note that semisync replication is in fact a plugin.
So times may be changing… sort of. Yesterday I noted that some storage engine API features are only available if you’re InnoDB and I’ve voiced my general disappointment in the audit API being unsuitable to implement various forms of query logging already in the server (general query log, slow query log).
One thing to note: when the API is the same for both inside the server and a plugin, it makes initial refactoring very easy, and you quickly see the bits that could be improved.
-
Hint of the day: Warning level in Error Log to see Aborted Connections
log_warnings = 2
Yields useful information in the MariaDB or MySQL error log file (or syslog on Debian/Ubuntu) you don’t want to miss out on.
You will know about aborted connections, which are otherwise only visible through global status as Aborted_connects (lost connection before they completed authentication) and Aborted_clients (cut fully authenticated connection).
It looks like
130523 2:14:05 [Warning] Aborted connection 173629 to db: 'unconnected' user: 'someapp' host: '10.2.0.50' (Unknown error)
You will know when, where from, and if for instance a wrong password was used you’ll see the username. Basically you’ll get as much info as the server has available at that point. Useful.
-
Why you shouldn't hire a devops
Lately there have been a lot of organisations trying to hire a devops engineer.
I myselve have been asked to fill in devops roles ..
There's a number of issues with that.
The biggest problem is that I always have to ask what exactly the organisation is looking for.
So you want a devops engineer with experience in Linux, MongoDB, MySQL and Java , does that mean you want a Java developer who is familiar with MySQL and Linux and breaths a devops Culture.
Or a Linux expert who understands Java developers and knows how to tune Mongo and MySQL ?
It's absolutely unclear what you want when you are hiring "A devops engineer"
The second problem is that you are trying to hire people who are knowledgeable about devops,
Yet a lot of those people know that you can't do devops on your own , devops is not a jobtitle. devops is not a new devops team you create.
To some of them you are even making a fool out of yourselve, as to them you show that you don't understand devops
On top .. the ones that do apply for this fancy new devops role, are the ones that might not get the fact that the problem isn't about tooling but about people working together and helping eachother , so you end up hiring the wrong people.
Even in todays devops culture a system engineer is still a system engineer, and a developer is still a developer.
You might have developers supporting the build tool chain, or system engineers focussing on infrastructure automation.
But as John said almost 3 years ago they are good at their job.
Devops is not a word you slap onto a tool, a team or a person and expect magic to happen
Let's face it .. devops is hard, you can't do this on your own .. you need to find the right people ..
|
News Feeds