After restarting or updating my Openshift application, the MySQL cartridge starts with event_scheduler off.
I tried adding an environment variable to have it started in "on" mode (as suggested in the my.cnf file), but it still doesn't work
>rhc env-list app-name
RSA 1024 bit CA certificates are loaded due to old openssl compatibility
OPENSHIFT_MYSQL_EVENT_SCHEDULER=on
So my question is, how to make it so the event_scheduler is always on, even after restart?
The OPENSHIFT_MYSQL_EVENT_SCHEDULER does not seem to be supported. The supported configurable values are listed in the my.cnf file below the # Configurable Values: line.
If you's like to see that implemented into the MySQL add-on cartridge, you can add the idea to http://openshift.uservoice.com and get others to vote on it.
Related
mysql is a common database and it supports kinds of configuration and tune parameters such as character_set_server, innodb_log_file_size and so on. These backend parameters are set under e.g. /etc/mysql/mysql.cnf configuration file and below the [mysqld] section, and take effect after service mysql restart.
There exists a situation where a single mysql server is providing database service for more than one application (on the same physical machine), and each of the applications may has its own officially recommended backend parameter settings.
However, it may happens when the parameters of different applications differ from each other and it may become worse when there are conflicts between application settings, for example, app A needs utf8 as the character encoding method and app B is using another one.
So, is there any mysqld configuration method to support this situation, or the right way is to start multiple mysql instances with each tuned for one application.
Thanks a lot!
I found the mysqld_multi solution from mysql official site solved my problems, which can start multiple mysqld processes and each one could has its own configurations.
In MySQL 8.0.12 running on Windows 10, it seems impossible to set lower_case_table_names to 2, so as to achieve the appearance of mixed case DB and table names in Workbench. I realize that under the hood these objects may remain lower case, which is fine. But I want it to look right in Workbench, and I could always achieve this in previous versions of MySQL. When I attempt to do that and restart the service so it takes effect, the service crashes and stops. In the mysql logs I see this:
Different lower_case_table_names settings for server ('2') and data
dictionary ('1').
Data Dictionary initialization failed.
This seems to be a common problem for a lot of people.
I read here that the solution is:
So lower_case_table_names needs to be set together with
--initialize.
But I have no idea what that means, or how to set it at startup. I have googled all over and read several forum articles but I can't find clear instructions on how to resolve this.
I figured it out. When installing MySQL Server 8.0.x, you have to check Show Advanced and Logging Options ...
...so that you can get to this screen:
Then you select Preserve Given Case, which is not the default. Hey MySQL developers: This setting should be on the main path, not buried in the optional advanced path.
===============================
Notes added on 9/25/2021:
This Preserve Given Case option can only be selected on first-time installation. You cannot go back and choose it later. Editing the
config file will only cause errors. Attempting to upgrade or modify
the install results in readonly options for this item.
If you already have MySQL installed without this desired option, you'll need to completely uninstall it and reinstall it.
As of MySQL 8.0.26, these steps are still valid.
===============================
8.0.11 changelog:
It is now prohibited to start the server with a lower_case_table_names setting that is different from the setting used when the server was initialized. The restriction is necessary because collations used by data dictionary table fields are based on the setting defined when the server is initialized, and restarting the server with a different setting would introduce inconsistencies with respect to how identifiers are ordered and compared. (Bug #27309094, Bug #89035)
See also: https://bugs.mysql.com/bug.php?id=89035
By --initialized, it is referring the initial install of 8.0. How was that done?
I read something about updating globals such as net_read_timeout, connect_timeout etc to avoid lost connection on MySQL databases. So my question is simply this
If I execute these queries, do I have to restart mysql service on Ubuntu & Nginx?
SET GLOBAL connect_timeout=28800
SET GLOBAL net_read_timeout=600
My question is really because when I use this query, it seems like they updated, but are they operating even though I don't restart mysql service etc?
SHOW VARIABLES LIKE '%timeout%'
Yes, they will definitely work. Only 'certain' OS's need rebooting after minor changes (I'm staying neutral). But don't take my word for it, see:
https://dev.mysql.com/doc/refman/5.7/en/server-system-variables.html
It says:
Most of them can be changed dynamically at runtime using the SET
statement, which enables you to modify operation of the server without
having to stop and restart it.
Then look in the table further down and you can see that connect_timeout and net_read_timeout are both dynamic.
I guess that the documentation has a purpose after all?
Does restarting the MySQL service on Linux, disables the already enabled general query logging?
There was a log file getting generated inside the data folder, and it was growing exponentially. The db has 100 requests per minute.
Initially i guessed, some transaction had broken in between, that made the logs to swell.
So i restarted the service, which stopped adding to that log file.
I checked the global variables and got to know the path was assigned for general_log_file. But now it was showing 'OFF'.
Hence my query
It's a common issue that people will set configuration of MySQL through dynamic (global) variables and forget to set the variables in the options file (my.conf). In that case, when the server is restarted, MySQL will revert to default settings.
The default setting for general_log is OFF. To immediately enable the general query log, set the global variable to ON. Then set the value for general-log in your my.conf file to ensure that the setting is applied whenever you restart MySQL server.
No, Restarting the server doesn't make the binary logs to OFF...
It may be the case that you changed the configuration file before and now restart takes that file...
MySQL will start with whatever options are in the file configuration. If you switched any of the global server variables before, they will be reverted to what is set in the file.
I need to set ft_min_word_len = 3.
I never restarted my mysql server on my production server. So I fear this moment :).
Are there any way to set ft_min_word_len = 3 without restarting mysql?
And if i must restart it, can you tell me the exact step I have to do?
I am on Devian GNU/Linux
MySQL: 5.0.32
(where I can find where is the mysql configuration file?)
Thanks a lot
No, I'm afraid you need to restart MySQL for it to accept the change. That said, there's nothing to be afraid of, as this won't affect any data. (If you're feeling paranoid, simply carry out the change/restart at an off-peak time, when site traffic is low.)
In terms of the configuration file, I think it lives in /etc/mysql/my.cnf on Debian. (If not, check /etc/my.cnf.)
To restart the service, simply issue a "/etc/init.d/mysql restart" command and all should be well.