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.
Related
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?
i have a local xampp, with php application runing on php5.6 and data base mysql are remote.
the issue is my application open very slow on my browser, is there an way to improve speed ?
mysql is on ssd server (fast)...
thanks
It's always going to be slower over a remote connection. How much really depends on a number of factors related to your connection, not really to MySql.
Few things to consider - do you really need to be working off the remote db? Can you use a local copy and sync changes later? Might even be faster to have your code remote and suffer the slightly longer save times when updating your code. Highly situational though depending on your dev set-up.
Another option which would be a bit more complicated is to set up your local db as a read-only slave and at least that way you get more of async update -- i.e., your local db may lag behind remote master a bit but any reads you do locally will be back to your "native" local performance. You would have the additional complexity of setting up Master/Slave replication with different connections for read/write but that may be something you want to do for production anyway. (You can do master/master but I wouldn't recommend it over a remote connection.)
Is it correct to use a backup of a vm as a means of restoring a MySQL database?
Are there any dangers in doing this?
My own feeling is that a vm backup/snapshot is at the os not the db level and therefore may not backup the database in the correct way. Has anybody any advice on this?
It's perfectly fine as long as you do one of two things:
Either ensure consistency of the tables by either shutting down the database or using something like FLUSH TABLES WITH READ LOCK while doing the snapshot (you probably don't want to do this)
Use a transactionally-safe storage engine such as InnoDB (the default) for all tables that are likely to change around the time of the snapshot, and rely on its ability to recover from what looks like a crashed state, i.e. the copy of a running server.
Once you realise that taking a snapshot of a running VM and booting the snapshot on another machine looks just like pulling the plug on that server and rebooting it, your choice becomes relatively easy: Make sure the system can recover from pulling the plug, and it can recover from a VM snapshot backup.
Based on a recommendation from Jeff Hunter posted on the VMWare blog, the answer is no, it's not safe to rely on the snapshots for MySQL backups. His recommendation is basically to dump the db through a separate process (and then allow the snapshot to copy the dump).
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.
Is there any way to get a fault tolerant MySQL replication? I am in an environment that has many networking issues. It appears that replication gets an error and just stops. I need it to continue to work and recover from these faults. There is some wrapper software that checks the state of replication and restarts it in the case of losing its log position. Is there an alternative?
Note:
Replication is done from an embedded computer with MySQL 4.1 to a external computer that has MySQL 5.0.45
What error are you getting? You also haven't described what replication scheme or Mysql version you're using. The errors you're getting are also important.
Replication usually stops when there's a primary/unique key conflict in a Master-Master replication. Other than that on a typical Master-Slave replication setup, networking issues shouldn't cause problems.
Try using Mysql 5.1 or newer, since replication in 5.0 is statement-based and causes problems in Master-Master setups, or when you're using stored-procedures.
(Also, stay away from Mysql Cluster ... noticed the advice on another comment).
Replication errors only happen if the databases get out of sync somehow, having the server simply continue would mean incoherent databases, I really doubt you'd want that.
In my experience, the only time you end up with such errors is if one of the master servers did not complete a query and the slave noticed.
In any case, if you really want to have the slave continue via some sort of chron job, you could always have a query run every few minuts asking the slave "SHOW SLAVE STATUS" then checking the error column, if it's present, send a "STOP SLAVE; SET GLOBAL SQL_SLAVE_SKIP_COUNTER; START SLAVE;" command. But it would probably be much more apt to send an email to an admin when mysql encounters an error instead, so he/she can investigate the source of the problem and make sure the databases are actually in sync, otherwise you're likely to see more errors in the near future as the databases become more and more out of sync.
Consider MySQL Cluster using the NDB storage engine, it's meant to be shared-nothing and fault tolerant
MySQL replication will normally detect problems and reconnect anyway, continuing from where it left off.
If you're getting replication errors, it's likely that the source is something else. MySQL replication effectively does a "tail -f" on the query log and replays it on the slave (it's slightly smarter than that, but not much).
If the databases become out of sync, MySQL replication will neither detect nor repair this, but it may eventually cause it to break as a subsequent update cannot proceed due to conflicting data on the slave.
The default timeouts on the replication slave are much too long - it waits hours (or something) - you'll want to reduce this.
Data becoming out of sync is difficult to avoid, mitigation steps are:
Monitor replication using something like mk-table-checksum from Maatkit
Audit all your code for replication-unsafe queries
If using 5.1, switch to row-based replication, which is less likely to suffer from this problem