Announcing release for MySQL 5.5 and 5.6 on CentOS Linux 6 and 7 x86_64 SCL
I am pleased to announce the immediate availability of versions 5.5 and 5.6 of the MySQL on CentOS Linux 6 and 7 x86_64, delivered via a Software Collection (SCL) built by the SCLo Special Interest Group (https://wiki.centos.org/SpecialInterestGroup/SCLo). QuickStart -- You can get started in three easy steps (example of MySQL 5.6): $ sudo yum install centos-release-scl $ sudo yum install rh-mysql56 $ scl enable rh-mysql56 bash At this point you should be able to use MySQL just as a normal application. An examples of commands run might be: $ service rh-mysql56-mysqld start $ mysql In order to view the individual components included in this collection, including additional subpackages plugins, you can run: $ sudo yum list rh-mysql56\* About Software Collections -- Software Collections give you the power to build, install, and use multiple versions of software on the same system, without affecting system-wide installed packages. Each collection is delivered as a group of RPMs, with the grouping being done using the name of the collection as a prefix of all packages that are part of the software collection. The collection rh-mysql56 delivers version 5.6 of the MySQL server (with daemon called rh-mysql56-mysqld) and related client tools. The collection mysql55 delivers version 5.5 of the MySQL server (with daemon called mysql55-mysqld) and related client tools. Both the collections include no client library libmysqlclient.so and client applications are advised to use the client library available in mysql-libs package from base system. For more on the MySQL, see https://www.mysql.com. The SCLo SIG in CentOS -- The Software Collections SIG group is an open community group co-ordinating the development of the SCL technology, and helping curate a reference set of collections. In addition to the MySQL collections being released here, we also build and deliver other databases, web servers, and language stacks including multiple versions of MariaDB, PostgreSQL, MongoDB Apache HTTP Server, NodeJS, Ruby, Python and others. Software Collections SIG release was announced at https://lists.centos.org/pipermail/centos-announce/2015-October/021446.html You can learn more about Software Collections concepts at: http://softwarecollections.org You can find information on the SIG at https://wiki.centos.org/SpecialInterestGroup/SCLo ; this includes howto get involved and help with the effort. We meet every second Wednesday at 16:00 UTC in #centos-devel (ref: https://www.centos.org/community/calendar), for an informal open forum open to anyone who might have comments, concerns or wants to get started with SCL's in CentOS. Enjoy! Honza SCLo SIG member -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql
Older mysql client with newer server compatibility
Hi experts, I'm thinking about compatibility issues between older mysql client (say 5.0.x or 5.1.x) with newer mysql server (5.5.x or 5.6.x). After some tests I've noticed no issues and it seems to work just fine. Is anybody aware of some problems that I can expect? Cheers, Honza -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql
Re: Older mysql client with newer server compatibility
On 09/17/2012 11:08 AM, Reindl Harald wrote: Am 17.09.2012 10:53, schrieb Honza Horak: I'm thinking about compatibility issues between older mysql client (say 5.0.x or 5.1.x) with newer mysql server (5.5.x or 5.6.x). After some tests I've noticed no issues and it seems to work just fine. Is anybody aware of some problems that I can expect? as long as protocols / authentications are not changed no problem above means: mysql client 4.0 can not connect to = 4.1 if the server is using old_passwords = 0 sql commands are sql commands, independent of the version Of course, so I can specify my question a little bit: Is anybody aware of any other backward incompatible change in protocol? Honza -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql
Re: RFE: Allow to use version-specific my.cnf files
On 04/27/2012 03:26 PM, Shawn Green wrote: I frequently need to have multiple versions ready to operate on my machine at any time. I solved the configuration file problems by only setting them up in the basedir of the installed version. For those special occasions when I need to configure multiple copies of the same version, I create a separate set of --datadir folders and craft separate configuration files for both. I start mysqld using the --defaults-file option and point that at the special file for each instance. As a matter of convenience, if you need to constantly run with multiple instances on the same host and if any one of those may need to be using a different version than the others, then the utility mysqld_multi may be what you need to be looking at. Each instance you manage by the script can have their own separate set of settings all stored in the same, common, configuration file. Check it out: http://dev.mysql.com/doc/refman/5.1/en/mysqld-multi.html Hi Shawn, thanks for pointing to that. So we have a possibility to define different options for different server instances using mysqld_multi. My proposal allows to have something similar for clients as well (without need to specify any command-line argument), or in cases when we want to define the same options to more servers, according to their version. It's probably nothing we cannot do now. But it could be a nice option, much more cleaner in some environments. Cheers, Honza -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql
Re: RFE: Allow to use version-specific my.cnf files
On 04/25/2012 05:52 PM, Andrés Tello wrote:
Reads interesting, but...
Why would you need that?
I mean... If I run several databases in the same hardware, I use completely
diferent paths for evertying, so I can have atomic, clean and specific
files for each instance/version of the database
Thanks for your opinion.
You're right, it doesn't make too much sense regarding system-wide
configuration files, such as /etc/my.cnf. A real use case I see is when
we speak about users' config files, like ~/.my.cnf.
Let's say we have two different MySQL versions on one hardware, then
it's possible we'll need a bit different options for each instance.
MySQL unfortunately doesn't distinguish between user-specific (usually
called rc files) and system-wide config files. Trying to have the patch
simple, I applied the feature to all config files (which was not necessary).
The attached patch now is a bit more complicated, but restricts the
feature only for config files in user's home directory. I believe this
makes more sense, than the original one.
Any comments welcome again.
Cheers,
Honza
diff -up mysql-5.5.22/mysys/default.c.versionedcnf mysql-5.5.22/mysys/default.c
--- mysql-5.5.22/mysys/default.c.versionedcnf 2012-03-02 20:44:47.0 +0100
+++ mysql-5.5.22/mysys/default.c 2012-04-27 09:44:01.136938181 +0200
@@ -37,6 +37,7 @@
#include m_string.h
#include m_ctype.h
#include my_dir.h
+#include mysql_version.h
#ifdef __WIN__
#include winbase.h
#endif
@@ -660,18 +661,24 @@ static int search_default_file(Process_o
const char *config_file)
{
char **ext;
+ char **version_ext;
const char *empty_list[]= { , 0 };
+ const char *versioned_list[]= { , - MYSQL_SERVER_VERSION, 0 };
my_bool have_ext= fn_ext(config_file)[0] != 0;
const char **exts_to_use= have_ext ? empty_list : f_extensions;
+ const char **versioned_exts_to_use= (dir[0] == FN_HOMELIB) ? versioned_list : empty_list;
for (ext= (char**) exts_to_use; *ext; ext++)
- {
-int error;
-if ((error= search_default_file_with_ext(opt_handler, handler_ctx,
- dir, *ext,
- config_file, 0)) 0)
- return error;
- }
+for (version_ext= (char**) versioned_exts_to_use; *version_ext; version_ext++)
+{
+ int error;
+ char full_ext[FN_REFLEN + sizeof(MYSQL_SERVER_VERSION) + 2];
+ strxmov(full_ext,*ext,*version_ext,NullS);
+ if ((error= search_default_file_with_ext(opt_handler, handler_ctx,
+ dir, full_ext,
+ config_file, 0)) 0)
+return error;
+}
return 0;
}
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/mysql
RFE: Allow to use version-specific my.cnf files
Hi,
PostgreSQL allows to use version-specific configuration files, which
allows to change some settings only for particular version of DB.
I think a similar enhancement would be nice and usable for
administrators of MySQL as well.
Please, consider the attached patch as a simple proposal. Any comments
are welcome.
Cheers,
Honza
diff -up mysql-5.5.22/mysys/default.c.versionedcnf mysql-5.5.22/mysys/default.c
--- mysql-5.5.22/mysys/default.c.versionedcnf 2012-03-02 20:44:47.0 +0100
+++ mysql-5.5.22/mysys/default.c 2012-04-25 14:51:32.824181063 +0200
@@ -37,6 +37,7 @@
#include m_string.h
#include m_ctype.h
#include my_dir.h
+#include mysql_version.h
#ifdef __WIN__
#include winbase.h
#endif
@@ -94,10 +95,10 @@ static my_bool defaults_already_read= FA
static const char **default_directories = NULL;
#ifdef __WIN__
-static const char *f_extensions[]= { .ini, .cnf, 0 };
+static const char *f_extensions[]= { .ini, .cnf, .ini- MYSQL_SERVER_VERSION, .cnf- MYSQL_SERVER_VERSION, 0 };
#define NEWLINE \r\n
#else
-static const char *f_extensions[]= { .cnf, 0 };
+static const char *f_extensions[]= { .cnf, .cnf- MYSQL_SERVER_VERSION, 0 };
#define NEWLINE \n
#endif
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/mysql
Re: logrotate script doesn't create a new log file
On 02/22/2012 07:58 PM, Johan De Meersman wrote: Having this line commented, we have to rely on logrotate.conf to have something similar defined and we see an error when using mysql-rotate Then something else is wrong. Does your MySQL daemon happen to run as a user who can normally not create files in the directory where the log files are? This seems to be the reason. MySQL is run under mysql user and the log file is located under /var/log in Fedora, so the daemon doesn't have enough privileges. It's clear now, we'd need to un-comment the line in such configuration. Thanks for the tip. Honza -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql
logrotate script doesn't create a new log file
Hi all, I'm thinking of logrotate script, that is shipped in mysql tar ball (e.g. mysql-5.5.20/support-files/mysql-log-rotate.sh). There is a commented line # create 600 mysql mysql, that should originally ensure logrotate utility creates a new log file after rotating. Is there any particular reason why the line is not used by default? Having this line commented, we have to rely on logrotate.conf to have something similar defined and we see an error when using mysql-rotate script alone, such as: logrotate -f /etc/logrotate.d/mysqld I think the line shouldn't be commented by default. Any thoughts appreciated. Thanks. Honza -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql
