We are planning on a Webinar in January about security for Web applications. We will cover topics such as encryption, authentication, data integrity and securing Linux/Unix and MySQL.

This webinar will be limited to the Sun Startup Essentials members.

If you ave any questions related to security, let us know in advance - I'll be checking the comments.

Nous planifions un Webinar en janvier sur le sujet de la sécurité pour les applications Web. Y seront abordés des sujets tels que l'encryption, l'authentification, SSL, la sécurisation des données, la sécurité Linux/Unix et MySQL.

Ce Webinar sera réservé aux membres de Sun Startup Essentials.

Si vous avez des questions sur la sécurités vous pouvez d'ores et déjà les partagers avec nous - je lirai les commentaires.

Today we're releasing MySQL Connector/Python 0.1.0-devel. This is the first in a serie of development snapshots aimed to get more people trying it out and reporting problems. This is not a production-ready release, but it should work on all Unices and Windows which has Python 2.4 or later installed. (No, no Py3K, yet!)

You can download it from Launchpad: there is a .tar.gz and .zip

There will be documentation and tutorial, but installation is as easy as pie (pun intended):

 shell> tar xzf mysql-connector-python-0.1.0-devel.tar.gz
 shell> cd mysql-connector-python-0.1.0-devel
 shell> python ./setup.py install

If you …

It seems to be impossible to perform client-side paging full table scans within MySQL.

For example, say you want to take a 1GB file and page through it 10MB at a time.

With a flat file I could just read 10MB off disk, read the next 10MB, etc.

This would be amazingly efficient as you could write the data sequentially, without updating indexes, and then read the data back out by byte offset.

You could page through MySQL tables by adding an index to a table:

SELECT * FROM FOO WHERE PTR > 10000 LIMIT 10000;

for example … but I REALLY want to avoid an index step because it is not cheap and only required since MySQL doesn’t support cursors.

This index slows down the import stage and I have to buffer the index data in memory which is just a waste.

I could use LIMIT with OFFSET but this isn’t going to be amazingly efficient because it will either require us to use …

Shared-disk databases can be virtualized—making them cloud-friendly—while shared-nothing databases are tied to a specific computer and a specific data set or data partition.

The underlying principle of the shared-nothing RDBMS is that a single master server owns its specific set of data. That data is not shared, hence the name shared-nothing. Because there is no ability to share the data, there is also no ability to virtualize the computing of that data. Instead the shared-nothing RDBMS ties the data and the computing to a specific computer. This association with a physical machine is then reinforced at the application level. Applications leveraging a shared-nothing database, that is partitioned across more than one server, use routing code. Routing code simply directs the various database requests to the servers that own the data being requested. In other words, the application must know which server owns which piece of data. …

Jonas improved the node failure handling in MySQL Cluster 7.0.9 (and 6.3.29) so here comes a re-run of the a previous blog post. And the node failure handling time has improved a lot - see below.

I created in total 11345 tables, each with 128 columns, and then hit this bug.

When all tables were created, I stopped one node and measured how long time it takes for the other node to perform the node failure handling. Here is what was written into the cluster log (look at the bold lines):

2009-11-27 13:39:21 [MgmtSrvr] ALERT    -- Node 4: Node 3 Disconnected

2009-11-27 13:39:21 [MgmtSrvr] ALERT    -- Node 4: Network partitioning - arbitration required

2009-11-27 13:39:21 [MgmtSrvr] INFO     -- Node 4: President restarts …

In my previous post I looked into how large table_cache actually can decrease performance. The "miss" path is getting more expensive very quickly as table cache growths so if you're going to have high miss ratio anyway you're better off with small table cache.

What I have not checked though is how does table_cache (or table_open_cache in newer version) size affects the hit path.

I started with the same test as last time - created 100000 tables and read all of them at once to make sure all table cache entries are populated. When I tried repeatedly reading 1000 empty tables with table_cache of 20000 and 2000. With Table Cache of 2000 I got about 16400 selects/sec with Table Cache of 20000 13500 selects/sec. So there is some slow down in hit path as well though it is not as large as with miss …

Happy Holidays!

Black Friday is back. We are happy to offer a 50% flat discount on all Webyog products. Yes, you read it right, fifty percent flat discount. Hurry up, this offer is valid only till 1st Dec 09, 23:59 PST.

Still using SQLyog Community Edition? Held off buying SQLyog Enterprise Edition? This offer is literally too good to pass up. Its time to own your copy of SQLyog Enterprise with all the PowerTools. Check out what Enterprise Edition has to offer.

Worried about your MySQL server’s health? Monitor it like a PRO. Get MONyog – MySQL Monitor & Advisor. Your MySQL DBA in a box! Check what it has to offer.

Want to extend your maintenance period? Don’t think twice, head right away to …

When moving from two data nodes to a bigger Cluster it is not necessarily true that you will have better performance. In fact you can get worse.

Here are some things to think about:

• Database Load (traffic to Cluster) - if you can handle query load X on a two node cluster and move the same load X to a four data node cluster you will likely get new_load_X=0.8X, i.e., a performance degradation. This has to do with 1) buffers are not filled up fast enough so the data nodes will do "timeout" based sending or 2) that the access patterns aren't scaling. To correct 1) you need to increase the load on the cluster so that internal communication buffers fill up faster.
  

Access pattern related "problems":

• For primary key operations (reads, updates, deletes) you will always go to the correct node to fetch the data with PK operations, no matter how many nodes you have. So no …

Configurator and Sandbox scripts are updated to use 7.0.9b.

You are recommended to upgrade!

Upgrade can be performend using these scripts:
Binary distribution - Upgrade script from 7.0.* -> 7.0.9b is here.
Source distribution - Upgrade script from 7.0.* -> 7.0.9b is here.

1. Copy the scripts to "install/"
2. chmod u+x upgrade-script.sh
   
3. ./upgrade-script.sh

After step 3) you need to run either:

• download-binary.sh
• download-and-compile.sh

and then