If you’ve been following this blog for long, you know what’s about to happen: another look at one-click installers available with the WebFaction control panel. This entry covers private database instances for MySQL and PostgreSQL.
For most applications, the shared MySQL and PostgreSQL databases are appropriate and easy to use. Routine database management, like creating databases and database users, can be done with the WebFaction control panel. The shared databases are also available by way of the phpMyAdmin and phpPgAdmin web-based administration tools for running queries and exploring your data. For the vast majority of use cases, the shared databases are a sensible choice.
But in some circumstances, we recommend the use of the private database instance installers for MySQL and PostgreSQL. In particular, private database instances are known to be useful in two special cases: custom configuration and the “bad neighbor” problem.
Private databases are handy when you want to take control of your database configuration. The shared databases are managed by the system administration team, so you cannot alter their settings. With a private database instance, you can change configuration values to your own specific needs, but without the hassle of compiling up from scratch.
Private databases are also useful when the “bad neighbor” problem presents itself. A “bad neighbor” appears when one database user consumes significantly more of the shared database’s resources than others. Switching that user from a shared database to a private instance makes performance expectations more consistent for all users on the server.
Both the PostgreSQL and MySQL installers benefit from using the server’s globally installed binaries and libraries, so you don’t have to worry about updating the database after security releases. When a private instance is installed, the installer creates two cronjobs: one to make sure the database is up and running every 20 minutes, and another to dump all of the instances databases to a file once per day. For more information, check out our private database documentation, including sample usage for Django and WordPress applications.
If a private database instance sounds like it might be useful to you, give it a try, and if you have any questions or need any help, join us in the Q&A Community.
A database created with the control panel runs on your server’s shared database process. The shared server is more convenient than configuring your own and doesn’t count toward your account’s memory usage.
Different applications have different needs, so every WebFaction server supports both MySQL and PostgreSQL. MySQL is extremely popular and is used in several of our one-click installers, including WordPress and Drupal. PostgreSQL is growing in popularity and sports some exciting features, like procedural languages PL/Perl and PL/Tcl.
Once you’ve created your database of choice, it’s easy to connect to it and start storing data. Check out these documentation sections:
Although the shared database and the associated documentation is convenient, it’s not necessarily for everyone. That’s why we recently introduced a one-click installer for private MySQL and PostgreSQL instances. A private database is a good option if you’re facing problems with contention on the shared database or if you want to customize the database configuration.
And, of course, you can always set up and run a specialty database from your home directory on your own. For example, check out our instructions on installing MongoDB.
For more details, see the WebFaction User Guide page Databases. If you have any questions, let us know in the comments or join us in the Q&A communtity.
Today we’re proud to show you the newest update to the WebFaction control panel. We’ve upgraded the way you create and manage MySQL and PostgreSQL databases and users, as a part of our ongoing effort to make the control panel easier to use. We’ve made this two-minute video to show off how the new interface works:
The new databases interface is more flexible when it comes to creating databases and determining who can access them. In the past, database names were required to begin with your username and an underscore. The new databases interface throws that requirement out the window. Starting today, you can name your databases as you please. Perhaps more importantly, now you can grant a single user access to multiple databases, and more than one user may be granted access to any one database.
In addition to the video, we’ve updated our documentation to reflect the latest changes to the control panel. Let us know what you think in the comments and if you run into any problems, join us in the Q&A Community.
Last November we announced that we were using cgroups on our shared servers to protect users from each other and get rid of the “bad neighbor problem”. This works great but there is still one potential problem: many apps on a server use the shared MySql instance on that server and one user can still use more MySql resources than their fair share and therefore affect all other users on that MySql instance.
To fix that problem we have added another application to our one-click installer: a private MySql instance. This sets up a private MySql instance running as your user on the server. A few points about this instance:
It uses the globally installed MySql binaries and libraries. This means that if a security hole is found in that version of MySql we apply the patch for you and you don’t have to do anything.
On Centos-6 servers (web300 and over) it runs MySql-5.5 and on Centos-5 servers it runs MySql-5.0.
The MySql configuration files and data files are owned by you and the MySql processes run as you. This means that you have full control over your MySql instance: you can configure it however you like and you can stop it and start it whenever you like.
By default you get a cronjob that monitors your MySql instance every 20 minutes and restarts it if it’s down.
By default you get a cronjob that dumps all the databases in that instance every 24h and another one that deletes these dumps after a week. This is because MySql recommends backing up a dump of your databases rather than directly backing up the MySql data files.
Note that a private MySql instance can use between 50MB and hundreds of MBs of memory depending on how it’s configured and how much data you’re storing. So if you’re going to use it for anything non-trivial we recommend getting at least 512MB of memory on your account or using one of our new 1GB, 2GB or 4GB plans.