Backing up MySQL Database most people compress them - which can make a good sense in terms of backup and recovery speed as well as space needed or be a serious bottleneck depending on circumstances and approach used.

First I should mention this question mainly arises for medium and large size databases - for databases below 100GB in size compression performance is usually not the problem (though backup impact on server performance may well be).

We also assume backup is done on physical level here (cold backup, slave backup, innodb hot backup or snapshot backup) as this is only way practical at this point for databases of decent size.

Two important compression questions you need to decide for backup is where to do compression (on the source or target server if you backup over network) and which compression software to use.

Compression on source server is most typical approach and it is great, …

If you're around Brisbane, do join us next Tuesday evening for a combined MySQL/PHP meetup... info at http://mysql.meetup.com/84/

Ian Clatworthy (Canonical) will be presenting on Distributed Version Control, such as is used in Bazaar, Mercurial and Git. You may be using SVN/SVK now, but DVCS is definitely worth a look; it's a different approach that makes you (and your team) more productive, and avoids many common version control problems (think "everybody stop working we're doing a merge", or "eek I had this right half a hour ago").

To give you an idea of how important this stuff is.... a brief snip from a conversation I just had with a developer:D: I was wondering whether you got to set up that mercurial repository?
A: sorry not yet. but I presume you've created a local one with hg init so that can be pushed at any time when I create it, it won't …

While this blog is co-authored by the whole MySQL Telecom team, many members in or around the team also write their personal blogs, which you will find very useful. So please follow me on a tour on the absolute top MySQL Cluster blogs in the world:

Johan Andersson is the MySQL Cluster Principal Consultant, and has been with MySQL Cluster since the Ericsson days. He travels around the world to our most demanding customers and shares his guru advice. Rumor has it that recently on a training gig the students made him sign their MySQL t-shirts, can you get closer to living like a rock star than this? Occasionally he also shares some great tips and status info on his blog. Like right now you can find a set of handy scripts to manage all of your MySQL Cluster from one command line, definitively recommended to try!

…

While this blog is co-authored by the whole MySQL Telecom team, many members in or around the team also write their personal blogs, which you will find very useful. So please follow me on a tour on the absolute top MySQL Cluster blogs in the world:

Johan Andersson is the MySQL Cluster Principal Consultant, and has been with MySQL Cluster since the Ericsson days. He travels around the world to our most demanding customers and shares his guru advice. Rumor has it that recently on a training gig the students made him sign their MySQL t-shirts, can you get closer to living like a rock star than this? Occasionally he also shares some great tips and status info on his blog. Like right now you can find a set of handy scripts to manage all of your MySQL Cluster from one command line, definitively recommended to try!

…

Big changes in this release.

Features:

• Talkback report for local script backups to report back to monolith console
• Status page now summarizes all Codes and failed server connections for past 24 hours
• Install now has correct data import for user setup and system settings
• More GRAPHS!
• Improved logic for analytics and automated tuning recommendations, fixed thread_status bug
• Change request document generation
• Full HTML reporting for statistics gathering and tuning report
• XML API page for custom export of data with all fields available for output
• Integrates with VisualMining: see api-monitor-visualmining.php file
• Data table for index+data size reporting of all monitored databases
• Improved table information gathering via INFORMATION_SCHEMA - no more SHOW commands …

Today High Performance MySQL, Second Edition went to press. I’ve been working with the production team over the last couple of weeks, proofreading and checking the index and working with the artist who re-drew the illustrations. I spoke to the production editor this morning and she told me the schedule is for the bound-book date to be the 16th of June. The official in-stock date is June 19th. I don’t know how many copies they’re printing for the first printing.

As a consultant, I do a lot of content migrations for clients. One issue I run into quite often is the encoding of databases, tables, columns differs between source and destination. Most clients do not want me to go and change the way their encoding is to fix issues since they are too afraid about messing with production data. Of course amongst other issues, it creates weird characters for data which is copied/pasted from Microsoft Word. You see weird characters like: ’ … – “ †‘

So if you just want to replace these with appropriate symbols, you may do it with a simple sql query. Note that below queries are without where clause. You may what to test it with one of your rows before making changes to the whole table. Of course, you should always backup your data before you try this out. If you have a dev system, that is even better. I put …

On MySQL developers zone there is a quick poll on which operating system you use.

The combined results of all Linux flavors accounts for 50% of the answers so far. What surprised me is the 6% of mac OSX used as a server. My own experience with macs is just as desktop or laptop. In my very personal view, it feels like a waste to use such a beautiful thing like a Mac as a server. Linux, as Neal Stephenson put it in In The Beginning Was The Command Line is like a tank. Efficient but not appealing, compared to Macs, which are described as stylish cars.
So, if business is a battle, the Linux tank seems your …

In my post from yesterday, I ended up resorting to using multiple-column fulltext indexes to make it so I was actually using the indexes on the columns specified in the query. Well, that worked. But it also resulted in HUGE indexes!

Before change:

-rw-rw---- 1 mysql mysql 1177773692 2008-06-05 12:37 items_text.MYD
-rw-rw---- 1 mysql mysql 1136713728 2008-06-05 12:37 items_text.MYI

After adding more indexes:

-rw-rw---- 1 mysql mysql 1156516200 2008-06-04 17:14 items_text.MYD
-rw-rw---- 1 mysql mysql 1978787840 2008-06-04 17:14 items_text.MYI

Furthermore, this made the table much harder to update. Replication kept lagging last night (nagios was complaining loudly).

I've since reverted back to the way I had it, not using the index, which is the least worse of my …

1) Which operations can I perform during a table reorg?
everything except DDL and node restart
ndb does currently only allow one DDL at a time, and the reorg is a DDL
ndb does currently prevent node restart while DDL in ongoing

2) What happens to an ongoing table reorg during
2a) node failure
reorg will be completed or aborted depending on how long it has progressed
(i.e if commit has been started)
2b) cluster failure, and recovery?
reorg will be completed or aborted depending on how long it has progressed
(i.e if commit has been written)

The reorg is committed after rows have been copied, but before rows has been
deleted/cleaned up

3) How do my a) SQL b) NDBAPI applications have to be changed to cope with table reorg?

Not at all, but
- your application can "hint" incorrectly if it does not check table state …