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.
Related
Good morning.
I've a MariaDB environtment, with a very basic my.cnf on it. Coming by default on product installation:
We've been working with this configuration from the beggining. So we have real productive data for a year long, on our DB.
If I substitute this my.cnf, by this one here:
https://gist.github.com/fevangelou/fb72f36bbe333e059b66
which is close to our instance specs (VM, quad-core 2.20Ghz, 8GB RAM), adapting it accordingly, do I have risk to corrupt, break, lose or dirtying existing data in any sense or meaning on DB? I mean, block size changes, buffer changes, etc. Is it dangerous?
In my case, we have this MariaDB on a WINDOWS instance Server 2k16 edition. So I would've to adapt this optimized config file. Then I should ask you too, do you have a basic/recommended optimized my.cnf file for Windows, like the one adove or so?
Thanks and regards.
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?
unfortunately I forgot to note down the new password from the last recovery. This means I can't login as root and the init script can't restart it due to not having been updated (sys_maint).
Is there a way for me to fix this, most of the guides I found require you to restart the mysql server, well, doesn't work in my case.
I could kill the process but am I able to start it up again afterwards?
If so I could probably use this way, if it works with mariadb:
http://dev.mysql.com/doc/refman/5.0/en/resetting-permissions.html#resetting-permissions-unix
After spending a few more hours with the issue I tried the one way and it even worked, though I didn't have any access to the database. So in terms of security concerns, well its even official..:
B.5.4.1.2 https://dev.mysql.com/doc/refman/5.0/en/resetting-permissions.html
I had a problem over the weekend. MySQL started giving "Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock'" Error over the weekend.
As suggested, I checked the location of the socket file, and it was in the right spot.
Then I checked the permission of the folders, and they were set to 0755.
Then I checked the disk space and there was plenty of it.
Then I performed a graceful server restart. That was what solved the problem.
My question, with these given, what can be the cause for this issue? This is our production server and I need to do due diligence an get to the root of this to prevent this from happening.
EDIT:
I am not attempting to resolve the issue, I am attempting to investigate the cause.
my.cnf has this set:
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
Thank you.
The last time I ran into this issue, I was able to get around it by setting the host parameter (-h127.0.0.1).
I'm not sure why it worked though, or rather, I'm not sure which specific configuration issues lead to it. Sometimes there can be different mysql.sock files at the same time, or in unexpected places (for example, on my last work machine I accidentally had three instances in different directories).
i need to update listen_addresses in postgres.conf file and want to avoid restart of postgres server process. I tried pg_ctl reload but its not working. Postgres documentation for this parameter says "This parameter can only be set at server start."
http://www.postgresql.org/docs/8.4/static/runtime-config-connection.html#GUC-LISTEN-ADDRESSES
It there any possible way to avoid the restart?
It there any possible way to avoid the restart?
No. That's why the documentation says it may only be set at restart.
If you can't afford the downtime for a simple database restart then you almost certainly need to have a connection pooling and failover system in place anyway. Start planning that so you can introduce it at the same time.
Also, 8.4 is old. If you're restarting a busy system anyway, consider planning an upgrade into the mix. Look at pg_upgrade.