Comments on: Possible Improvements to MySQL Administration http://blog.wl0.org/2009/07/possible-improvements-to-mysql-administration/ Random thoughts on different topics Fri, 27 Jan 2012 06:02:03 +0000 hourly 1 http://wordpress.org/?v=3.1.3 By: KB http://blog.wl0.org/2009/07/possible-improvements-to-mysql-administration/comment-page-1/#comment-1536 KB Thu, 07 Jan 2010 17:37:34 +0000 http://blog.wl0.org/?p=103#comment-1536 One feature of the admin environment I am in is our use of m4 to help us generate configs for several instances and make it very easy to template our setups. KB One feature of the admin environment I am in is our use of m4 to help us generate configs for several instances and make it very easy to template our setups.

KB

]]> By: sjmudd http://blog.wl0.org/2009/07/possible-improvements-to-mysql-administration/comment-page-1/#comment-661 sjmudd Thu, 23 Jul 2009 22:26:38 +0000 http://blog.wl0.org/?p=103#comment-661 Perhaps what you say has some truth. That doesn't mean that a non-root user can not be configured to have the right values. If that means setting things up correctly for the mysql user then so be it. Look at Sybase, or better Oracle, which are quite precise about the rights required to run correctly. Running as root is a bit lazy as you have all privileges and can change anything you want. mysqld_safe is really meant only to restart a crashed process. Hence leave the script to do that alone. I'd prefer to restart the system myself as perhaps mysqld won't recover properly or I want to investigate the cause of the crash. I'd like that option to be configurable from within my.cnf so that I can choose, and I don't mind if default behaviour is to enable mysqld_safe rather than just start up the binary without this safety net. Perhaps what you say has some truth. That doesn’t mean that a non-root user can not be configured to have the right values.

If that means setting things up correctly for the mysql user then so be it. Look at Sybase, or better Oracle, which are quite precise about the rights required to run correctly. Running as root is a bit lazy as you have all privileges and can change anything you want. mysqld_safe is really meant only to restart a crashed process. Hence leave the script to do that alone. I’d prefer to restart the system myself as perhaps mysqld won’t recover properly or I want to investigate the cause of the crash. I’d like that option to be configurable from within my.cnf so that I can choose, and I don’t mind if default behaviour is to enable mysqld_safe rather than just start up the binary without this safety net.

]]> By: Sheeri http://blog.wl0.org/2009/07/possible-improvements-to-mysql-administration/comment-page-1/#comment-651 Sheeri Thu, 23 Jul 2009 14:19:29 +0000 http://blog.wl0.org/?p=103#comment-651 The biggest reason I see for mysqld_safe to run as root is so that it can spawn mysqld and mysqld can inherit certain properties, such as ulimit values, from the root user. For example, file descriptors. I believe on Linux the default ulimit for non-root users for file descriptors is 1024 -- Just yesterday I ran into a client who had 595 Open_tables, a table_cache of 2048, and Opened_tables was rapidly increasing. Why? Because they couldn't do too many more than about 600 open tables without closing one, because they were running mysql with a user that had a ulimit -n of 1024. So that will definitely need to be taken into consideration. The biggest reason I see for mysqld_safe to run as root is so that it can spawn mysqld and mysqld can inherit certain properties, such as ulimit values, from the root user.

For example, file descriptors. I believe on Linux the default ulimit for non-root users for file descriptors is 1024 — Just yesterday I ran into a client who had 595 Open_tables, a table_cache of 2048, and Opened_tables was rapidly increasing. Why? Because they couldn’t do too many more than about 600 open tables without closing one, because they were running mysql with a user that had a ulimit -n of 1024.

So that will definitely need to be taken into consideration.

]]> By: sjmudd http://blog.wl0.org/2009/07/possible-improvements-to-mysql-administration/comment-page-1/#comment-647 sjmudd Thu, 23 Jul 2009 12:54:37 +0000 http://blog.wl0.org/?p=103#comment-647 Yes, I mainly agree with you. We previously had some production boxes running multiple instances and it's clear that they interfered with each other in ways which were quite unhelpful. Since then things have changed and production boxes work as you describe: 1 instance 1 box. We break this rule in development where for the most part performance is really not an issue and it would be a waste of resources to do things differently. However it is still inconvenient to have to use different procedures on dev boxes compared to production boxes. That's why I specifically mention the "multi-instance" issue. Yes, I mainly agree with you. We previously had some production boxes running multiple instances and it’s clear that they interfered with each other in ways which were quite unhelpful. Since then things have changed and production boxes work as you describe: 1 instance 1 box.

We break this rule in development where for the most part performance is really not an issue and it would be a waste of resources to do things differently. However it is still inconvenient to have to use different procedures on dev boxes compared to production boxes. That’s why I specifically mention the “multi-instance” issue.

]]> By: Matt Reid http://blog.wl0.org/2009/07/possible-improvements-to-mysql-administration/comment-page-1/#comment-635 Matt Reid Thu, 23 Jul 2009 05:34:17 +0000 http://blog.wl0.org/?p=103#comment-635 Some of these reasons and more are specifically why I despise running multiple instances of MySQL on one server. Aside from budget reasons I've never understood why anyone would want to run more than one instance per server. Resource allocation and troubleshooting are a major hassle on multiple instance servers, in addition to the annoyances you've mentioned in the article. If you need multiple instances on one physical server, install VMWare ESXi on the server and run one instance per virtual host. That's much simpler and much less hassle for everyone involved. Good write up though. :) Some of these reasons and more are specifically why I despise running multiple instances of MySQL on one server. Aside from budget reasons I’ve never understood why anyone would want to run more than one instance per server. Resource allocation and troubleshooting are a major hassle on multiple instance servers, in addition to the annoyances you’ve mentioned in the article.

If you need multiple instances on one physical server, install VMWare ESXi on the server and run one instance per virtual host. That’s much simpler and much less hassle for everyone involved.

Good write up though. :)

]]> By: Mark Callaghan http://blog.wl0.org/2009/07/possible-improvements-to-mysql-administration/comment-page-1/#comment-596 Mark Callaghan Wed, 22 Jul 2009 04:38:28 +0000 http://blog.wl0.org/?p=103#comment-596 You describe interesting issues. There is an opportunity for MySQL (official and the community) to provide a much better wrapper to manage mysqld. This is more of an issue when you run many instances. I have experienced a few cases where restarts of critical servers were missed and there were no alerts on Uptime going backwards. The value added mysqld wrapper can do more than just start mysqld and alert on crashes. It can also perform administrative tasks. You describe interesting issues. There is an opportunity for MySQL (official and the community) to provide a much better wrapper to manage mysqld. This is more of an issue when you run many instances. I have experienced a few cases where restarts of critical servers were missed and there were no alerts on Uptime going backwards.

The value added mysqld wrapper can do more than just start mysqld and alert on crashes. It can also perform administrative tasks.

]]> By: Arjen Lentz http://blog.wl0.org/2009/07/possible-improvements-to-mysql-administration/comment-page-1/#comment-594 Arjen Lentz Wed, 22 Jul 2009 01:10:53 +0000 http://blog.wl0.org/?p=103#comment-594 Simon; apart from some practicalities, excellent ideas. And they can be put in practice in 5.1, if you get involved with MariaDB and the OurDelta builds. See the respective projects and mailing lists on Launchpad, and the Freenode IRC channels #maria and #ourdelta. (toss me an email if you have difficulty finding something) Simon; apart from some practicalities, excellent ideas. And they can be put in practice in 5.1, if you get involved with MariaDB and the OurDelta builds.
See the respective projects and mailing lists on Launchpad, and the Freenode IRC channels #maria and #ourdelta.
(toss me an email if you have difficulty finding something)

]]> By: sjmudd http://blog.wl0.org/2009/07/possible-improvements-to-mysql-administration/comment-page-1/#comment-582 sjmudd Tue, 21 Jul 2009 22:25:40 +0000 http://blog.wl0.org/?p=103#comment-582 Hi. Maybe root access is not required but at least CentOS rpms run that way: <code> [root@mad06 ~]# ps auwx | grep mysqld_safe root 3184 0.0 0.0 65924 1364 ? S Jul05 0:00 /bin/sh /usr/bin/mysqld_safe --datadir=/var/lib/mysql --socket=/var/lib/mysql/mysql.sock --log-error=/var/log/mysqld.log --pid-file=/var/run/mysqld/mysqld.pid root 9580 0.0 0.0 61184 748 pts/5 S+ 00:21 0:00 grep mysqld_safe [root@mad06 ~]# rpm -qa | grep mysql mysql-devel-5.0.45-7.el5 mysql-5.0.45-7.el5 mysql-server-5.0.45-7.el5 [root@mad06 ~]# </code> These are RH provided rpms but MySQL Community and Enterprise rpms behave the same. We've spoken before about MySQL Sandbox and it does sound promising. I'm not entirely sure it's designed to cover all the things I mention and it's certainly not possible yet to incorporate it into the "standard" packages and startup scripts. However perhaps it's a promising move to make MySQL management better than it is at the moment. Hi. Maybe root access is not required but at least CentOS rpms run that way:


[root@mad06 ~]# ps auwx | grep mysqld_safe
root 3184 0.0 0.0 65924 1364 ? S Jul05 0:00 /bin/sh /usr/bin/mysqld_safe --datadir=/var/lib/mysql --socket=/var/lib/mysql/mysql.sock --log-error=/var/log/mysqld.log --pid-file=/var/run/mysqld/mysqld.pid
root 9580 0.0 0.0 61184 748 pts/5 S+ 00:21 0:00 grep mysqld_safe
[root@mad06 ~]# rpm -qa | grep mysql
mysql-devel-5.0.45-7.el5
mysql-5.0.45-7.el5
mysql-server-5.0.45-7.el5
[root@mad06 ~]#

These are RH provided rpms but MySQL Community and Enterprise rpms behave the same.

We’ve spoken before about MySQL Sandbox and it does sound promising. I’m not entirely sure it’s designed to cover all the things I mention and it’s certainly not possible yet to incorporate it into the “standard” packages and startup scripts. However perhaps it’s a promising move to make MySQL management better than it is at the moment.

]]> By: Giuseppe Maxia http://blog.wl0.org/2009/07/possible-improvements-to-mysql-administration/comment-page-1/#comment-581 Giuseppe Maxia Tue, 21 Jul 2009 22:18:58 +0000 http://blog.wl0.org/?p=103#comment-581 Hi, root access is not needed for mysqld_safe. Rather than mysqld_multi, you may want to try MySQL Sandbox (http://mysqlsandbox.net), which installs multiple servers, either single or in replication, each of them shielded from other instances. All of them in normal user space, without root access at all. (mysqld_safe is not optional at the moment, but it will be in the next version) Cheers Giuseppe Hi,
root access is not needed for mysqld_safe.
Rather than mysqld_multi, you may want to try MySQL Sandbox (http://mysqlsandbox.net), which installs multiple servers, either single or in replication, each of them shielded from other instances. All of them in normal user space, without root access at all. (mysqld_safe is not optional at the moment, but it will be in the next version)

Cheers

Giuseppe

]]>