Changes to MySQL: Quota Implementation

This post was published 2 years 22 days ago which means the content may no longer be applicable or relevant to the service we offer today. If in doubt, please contact us.

Following on from a previous post regarding MySQL usage consumption, we are intending to make changes to MySQL across all shared servers, and implement an effective MySQL quota. This post will contain all relevant information about the upcoming changes.

Why are you implementing a MySQL Quota?
Currently, MySQL databases are not limited in size, nor are they detracted from an accounts disk space quota. Under our Terms and Conditions we essentially implement a “fair usage” policy, and recommend that databases are no larger than 256MB to 512MB in size. Obviously as a hosting provider we need to draw the line between what is deemed acceptable for shared hosting, and what isn’t. Because of the nature of shared hosting, multiple large databases can and will increase MySQL memory usage on a server and can possibly reduce MySQL performance for others. Many customers are unaware of the MySQL information in our Acceptable Usage Policy, and as a result are exceeding (often very significantly) these guideline amounts. To try and keep performance the best we can, we feel that we need to begin implementing a MySQL quota so that databases simply cannot grow out of control on their own.

Our intention isn’t to charge people more (see below) or somehow otherwise inconvenience users, it’s merely to safeguard the integrity of our the servers by ensuring that particular resources cannot be abused or exceeded dramatically at the risk of performance degradation for others.

Why can’t you just combine the MySQL usage with the purchased disk space?
If we do this, and the disk space of a particular user is met or exceeded, MySQL will crash when new data is attempted to be added – bringing the service down for everyone.

What exactly is the quota going to do and what will happen if I reach it?
If a database exceeds our hard-coded quota, the “CREATE” and “INSERT” permissions on a database will be revoked. This will allow your databases to be used (such in a forum, it will still be accessible and readable by others), however new content (such as new forum posts) will be unable to be added and will generate a MySQL error upon query.

This quota is based on single, individual databases, and is not account bound.

The system will be 100% automated, so reducing your database size will cause the system to reinstate the relevant permissions within several minutes of making the changes.

What quota are you going to implement?
We are going to implement a 256MB quota, and modify our AUP Accordingly.

How do I know how big my databases are, and whether I’m at risk?
If you login to cPanel and access the ‘MySQL Databases’ screen, it will inform you how large each database is. Our investigations have shown that this quota limit will affect less than 1% of our hosted sites, so it is very unlikely to cause you any issues at all.

What do I do if my database is too large?
In many cases, the size of your database can be reduced by simply pruning old data. If you run a forum for example, deleting very old posts beyond a certain time period can clear up significant amounts of space.

I don’t want to delete old data, is there anything I can do? Can I upgrade to the Ultra plan and still use it?
I’m afraid not. If you are unable to bring your database size to below this new quota (256MB), you will need to seek an alternate method of hosting said database. In this instance we would recommend a VPS/Cloud hosted solution or Dedicated Server. Please contact us for possible options if you wish to persue hosting with us.

Please note that this quota is global and is not attached to particular accounts. If you are on the Ultra package or the Starter/Blog package – you will receive the same 256MB quota. Upgrading your package will not remove or increase this quota.

When will you implement this new quota system?
We will be bringing this new quota system online on February 1st 2010. This should allow ample time for existing customers to take the necessary steps to ensure they are not affected by this change.

As always, if you have any questions, comments or concerns, please let us know by either opening a ticket or responding to this blog post.

EDIT:

It seems that in some vBulletin databases, the ‘Attachments’ table can grow extremely large due to vBulletin defaulting to store attachments within the database instead of as files on the server. To remedy this please try the following solution:

“First go to the cPanel’s File Manager and create an “attachments” directory in your site’s offline root directory (the directory that File Manager defaults to) and CHMod it 777. Keeping this directory offline is good for security purposes (no one will be able to view attachments they do not have permission to view). Now go to the AdminCP, expand the Attachments list on the left side and click on Attachment Storage Type. Move your attachments out of the database and into the file system. Here is the path you will want to use, replacing yourCPanelusername with the username you use to login to cPanel:

/home/yourCPanelusername/attachments”

Many thanks to Chad for providing us with this information.