Well, I upgraded my MythTV setup to version 0.21 not because I had to, but I was curious about one of the new features which it supports - MultiRec. This feature allows one tv tuner to record more than one channel as long as they are on the same multiplex. This currently is not too useful as the multiplexed channels are those like 7 and 7HD or 10 and 10HD which usually have the same programs for 95% of the air time. One where it may become useful however is that of ABC1 and ABC2. These are distinctively different and I can now record both at the same time as well as using my second tuner for other recordings or watching. Well, it seems to work quite well and without any major adjustments to what you do normally.

I attended the Sun Tech Days last week here in Sydney, Australia with a number of objectives in mind. The first was to meet up with people I knew in Sun to see how the newly confirmed merger was working here in Australia and also to see some of the talks scheduled, particularly the database related ones.

Found an interesting situation today after being forced to send a fax via the Australian Post Office. I handed the fax over and they handed me a simple form to fill out. At first I thought it was simply the details such as local or international, the fax number etc. However as I continued, it asked for my full name and signature and listed some "terms" that I would agree to by signing the form.

I have been travelling and had not got my mobile broadband (minimax USB) account paid up to date so I arrived back home to find out that it was not working. No problem, I thought, I will just pay the small outstanding amount and get it reactivated. How quickly I had forgot how hard it is to deal with Telstra!

I called up Bigpond and followed through about 4 levels of options to get to the "specific" area for help with my problem. I wanted billing to find out how much I had to pay and get it sorted out. I found out then that apparently it was not billing nor even relevant to my account. They told me I had to talk with Telstra Mobile and gave me a 1300 number to call and then put me through.

Many businesses are now interested in implementing MySQL Cluster as a general high availability solution for their existing databases. This is certainly not a good approach and will often fail due to the limitations currently in the MySQL Cluster implementation (particularly 5.0) and the type of data within the business. However, many are still seeing MySQL Cluster as a magical solution to take out their potential downtime instead of other standard measures such as DRBD, multimaster or scale-out replication.

http://computerworld.co.nz/news.nsf/tech/A6AB17B34B1BA81ECC2573160079BFBC

This is an abstract from the above article from ComputerWorld magazine in New Zealand. There seems to be some misconceptions portrayed here and I would like to address them.

<extract>
“[But] there are issues which come with some open-source products,” says the AA’s CIO, Doug Wilson.

“The first, with Open Office, is compatibility — sharing information with Microsoft products, both within the organisation and with external parties. A dual world is complicated and, whether people like it or not, Microsoft is a standard.

Well, it seems many have put up their wishlist for features they would like to see in MySQL so here is my list. These are in no particular order of importance, just as they came to mind :)

1. Online Backup - This is currently being developed and it will make a big difference to many people currently trying to administrate MySQL. We can only hope that it gets done soon and is well tested to avoid any major issues.

2. Standardised HA/Replication - Along similar lines to the consistent online backup is that of consistent high availability, load balancing and replication. No matter what the engine being used, this will allow a consistent method of implementing these features regardless.

This article goes along similar lines to the piece I did on the security of MySQL. I came across another blog that asked about programming tips that really should not be followed in the real world. I thought it might be interesting to get some ideas of what areas of MySQL or database theory that is taught as "religion" at University or even in starting positions that just don't work in the real world in some situations.

I will get the ball rolling by adding a few points that are often drummed into people, but don't work in all situations.

Well the last day or two have been interesting here in Newcastle in the Hunter Valley. Last night we had a massive storm that to me appeared to be strong winds and rain, but without too much damage. I awoke this morning to continue the day as usual and found power, internet and hot water available as expected.

It was not until I went driving that I started to see the carnage that the storm had done. Of all the traffic lights I went through, only one was actually working - some of the roads were even blocked off from access. There were cars beside the roads and even on some where they had been flooded with water and left alone. Power lines down, countless trees down and limbs fallen - everywhere you look there were problems.

I came across a list of possible questions for a security panel and thought it may be interesting to apply some of them to MySQL and see what happens .

* What is the biggest challenge in data security?

I would suggest it is always the same problem with security - human error. It seems that no matter how well you protect the data, people will be the weakest link in the chain. This could come from social engineering, or to the point where the admin does silly things like deleting/dropping data from the wrong area.

How can we address this problem with MySQL? There are some configuration options that let you force safer interaction like safe-updates etc, but it will never be enough. Backups are probably the best answer.