Cybersite Consulting

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.

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.

The latest download binaries for SolidDB 5.0.41 version is now available. There were no major issues in the compilation, but I had to explicitly remove some of the GIS code due to errors. Note that this compilation is mainly for testing the Solid engine so I have simplified the option to exclude innodb (and most engines) and geometry capabilities, otherwise it is pretty much all there .

A precompiled binary is available for SolidMySQL 5.0.41-0073 for Mac OS X (PPC)

Please email me at info@cybersite.com.au if you have any problems with the binaries running. If you have issues with the storage engine itself, please read the documentation and forums at the SolidDB website.

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.

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.

I was out at lunch with some clients and started discussing properties of database systems and the idea of MySQL not having stored procedures popped up its ugly head again. I explained it did have stored procedures as from 5.0 version, but started a heated debate about whether they were actually of any use any more? Why was there a debate over this issue, I simply said, they are no longer important as they once were.

I put forward the question as to why stored procedures were used and after discussion everyone came to the opinion that they are used primarily for two purposes:

1. A data-level API interface.
2. For encapsulating and abstracting larger, multiple queries or transactions, thus keeping the load on the server, rather than on the network.

Everyone agreed that the second option was still valid, although seemed to be less required now, it was the idea of using stored procedures to maintain an API interface that was intriguing. Let me explain the scenario.

I thought about covering an issue that many people will come across when implementing MySQL Cluster if they are not aware of it. That is of bandwidth and latency in TCP/IP when implementing a transport over ethernet cabling.

The MySQL Cluster is always passing information between the different nodes that it contains. This is obvious for synchronisation and also for retrieval of data through the MySQL api nodes. When people first setup the cluster they often go for a default install on a higher speed network such as gigabit ethernet (GigE). This will probably work fine for very small data sets or initial testing data, but when the data becomes larger in size, the user realises very quickly that there is a lot of traffic passing through the network on the cluster.

I came across as interesting situation with MySQL that I had not come across before. Most people would not have come across this problem either as the majority of MySQL installs are either single server based. If there are multiple servers, then they are usually the same platform or very close eg. Linux on x86 etc.

The issue I came across was actually in respect to a MySQL Forums entry and this guy who was trying to replicate from Unix to Mac OS X. The problem was explained that the replication showed the status as normal, the read_master_pos_log and the exec_master_pos_log were all fine, and the relay logs were working. There was no errors showing and the replication seemed to be going through according to all system status reports. The issue was that no data was going in to the tables.