I have the following code that enables logical decoding in PostgreSQL 9.4:
pg_recvlogical -h localhost --slot test_slot --create-slot
pg_recvlogical -h localhost --slot test_slot --start -f -
I spawn a node.js subprocess to run this code and listen for changes however I'm unsure of what the correct procedure is to terminate the connection. I usually just CNTRL+C from the command line or kill the subprocess in code but I always get a pg_recvlogical: unexpected termination of replication stream: error. What is the correct way to terminate this connection?
The PostgreSQL documentation says,
--start
Begin streaming changes from the logical replication slot specified by --slot, continuing until terminated by a signal. If the server side change stream ends with a server shutdown or disconnect, retry in a loop unless --no-loop is specified.
So I assume the standard Linux signals meanings apply. Therefore, SIGINT or SIGQUIT should be acceptable, giving the app time to finish.
What I do is I send SIGINT, then enter a loop, check if /proc/$PID_/stat exists, and after custom timeout, I send it SIGKILL, and wait $PID_ for it.
kill -2 $PID_
for i in `seq 1 8`; do
if [ ! -f /proc/$PID_/stat ] ; then
RETURN_CODE=`wait $PID_`;
break;
fi
sleep 1;
done
if [ -f /proc/$PID_/stat ] ; then
kill -9 $PID_;
RETURN_CODE=`wait $PID_`;
fi
This is Bash, but any decent platform/language will have tools to do it.
Shortened, so there may be a bug :)
I did the following to kill a zombie active replication slot.
connect to the server where postgres is installed using CLI with ssh.
ssh -i <generated_security_key_name/path>.pem <username>#<hostIp>
once connected with the VM in your server. type following command to connect to postgres sql.
sudo -i -u <postgres-username>
you can go with psql which is a terminal-based front-end to PostgreSQL
psql
check the pid against your replication slot.
select * from pg_replication_slots;
Enter the following to kill it.
sudo kill <pid>
Related
Normally, when the command to start server is given as pg_ctl.exe -D ..\data -o"-p8028 -w start", the server waits until startup gets completed.
But my scenario is, I had forcefully shutdown the server using the -m immediate option. Then I tried to start the server with the command pg_ctl.exe -D ..\data -o"-p8028" -w start. While starting the server after immediate shutdown, it will move into the recovery mode.
So my question is, while starting the postgres server after immediate shutdown with the command pg_ctl.exe -D ..\data -o"-p8028" -w start, whether it will wait for the recovery mode to complete or not?
I found out that, even when we start the PostgreSQL server with the command
pg_ctl.exe -D ..\data -o"-p8028" -w start
it will not wait until the recovery mode is complete. It will wait for the time that we have specified during startup.
When trying to perform pg_basebackup on a replica, I always get the following message:
postgres#db1:~/10$ pg_basebackup -h foo.bar.com -U repluser -D /var/lib/postgresql/10/main -v -P
pg_basebackup: initiating base backup, waiting for checkpoint to complete
I've tried waiting, but nothing happens. Is it possible to speed up the process?
Call pg_basebackup with the option --checkpoint=fast to force a fast checkpoint rather than waiting for a spread one to complete.
It's possible to force a checkpoint to complete. To do so, run CHECKPOINT; on the master server:
$ sudo su - postgres
$ psql
postgres=# CHECKPOINT;
Wanted to point out that while the accepted answer of running 'CHECKPOINT' command on the primary server is correct, it is not meant to be run during normal operation, this is according to postgres documentation which you can see here:
https://www.postgresql.org/docs/current/sql-checkpoint.html
So be sure and not do this while the server is processing normal operations from your apps etc.
I am accessing my raspberry pi 3 from ssh. Can you tell me how to shut it down from ssh. Whenever I use sudo shutdown -h now the terminal just freezes without any output. If I kill the terminal I can ssh into raspberry again showing it did not shut down.
Add the -P flag:
sudo shutdown -h -P now
sudo shutdown -h now or sudo halt
You can’t use shutdown (or halt) unless you have sudo privileges.
-h instructs to halt the system, now means to run command right now. You can add a number X to tell it to shut down in X minutes. It also allows a specific time in this format XX:XX (note this is in 24 hour format seperated by a : colon).
sudo halt should be help you in this case
Just run sudo halt and wait until the green light turns off to power it off.
If you're on Linux, you should try:
sudo shutdown -h now && exit
A solution is to launch the shutdown in the background, with some delay to allow the user to safely exit the ssh connection.
Something like this :
{(sleep 5; sudo halt;) &}; exit
I created as script to suspend or shutdown a remote host over ssh. This may be used to suspend / shutdown a remote computer without an interactive session and yet not keep a terminal busy. You will need to give permissions to the remote user to shutdown / suspend using sudo without a password. Additionally, the local and remote machines should be set up to SSH without an interactive login. The script is more useful for suspending the machine as a suspended machine will not disconnect the terminal.
local_user#hostname:~$ ssh remote_user#remote_host "screen -d -m sudo pm-suspend"
source: कार्यशाला (Kāryaśālā)
Use the command systemctl poweroff
You will then be asked to authenticate yourself and enter your password. For reasons I don't know, it asks you to enter your password a second time.
Once authenticated, enter poweroff and the pi will shutdown.
I have a 2 node system running pacemaker, corosync and postgresql 9.4. I am carrying out pgsql replication using virtual IP and am able to successfully recover a downed machine using manual commands. Now to automate stuff, I want to run the following commands in a script to get my recovered master back on cluster.
`#su -postgres
$rm -rf /var/lib/pgsql/9.4/data/* //To delete old data files
$pg_basebackup -h 192.XX.XX.XX -U postgres -D /var/lib/pgsql/9.4/data -X stream -P // To recover the latest data from standby PC running latest entries
$rm /var/lib/pgsql/tmp/PGSQL.lock
$exit //exit from postgresql shell
#pcs resource cleanup msPostgresql`
Now when i run these commands as a script, it hangs after the first command itself i.e. su -postgres and the cursor blinks at bash$ syntax without inserting the commands down below.
I want to automate this process using cron but the script itself is not working for me. Can someone help me out here.
Regards
As far as I know "su -postgres" is wrong. You can use either "su postgres", or "sudo -i -u postgres"
Regarding the scripts here you can find tested, working scripts. The one you are interested in is called "initiate_replication.sh" there.
I want to run PostgreSQL 9.1 using Supervisor on Ubuntu 10.04. At the moment, I manually start PostgreSQL using the init script:
/etc/init.d/postgresql start
According to this post: http://nicksergeant.com/using-postgresql-with-supervisor-on-ubuntu-1010/, I need to modify the PostgreSQL config to make it run on TCP port instead of Unix socket, in order to make PostgreSQL work with Supervisor.
I have two questions regarding this approach:
Considering this is more of hack, is there any implication (e.g. security/permissions, performance, etc) of doing this?
Why cannot we just run the same init script postgresql in Supervisor config? Instead, as shown in the link above, it runs postmaster?
UPDATE:
Thanks to the useful suggestions from both answers below, I have setup a script for Supervisor to invoke PostgreSQL directly:
#!/bin/sh
# This script is run by Supervisor to start PostgreSQL 9.1 in foreground mode
if [ -d /var/run/postgresql ]; then
chmod 2775 /var/run/postgresql
else
install -d -m 2775 -o postgres -g postgres /var/run/postgresql
fi
exec su postgres -c "/usr/lib/postgresql/9.1/bin/postgres -D /var/lib/postgresql/9.1/main -c config_file=/etc/postgresql/9.1/main/postgresql.conf"
I also set the config: /etc/postgresql/9.1/main/start.conf to manual so that PostgreSQL does not start automatically on boot (however, it's not clear to me whether this config is loaded). And then I setup the Supervisor config for postgres as:
[program:postgres]
user=root
group=root
command=/usr/local/bin/run_postgresql.sh
autostart=true
autorestart=true
stderr_logfile=/home/www-data/logs/postgres_err.log
stdout_logfile=/home/www-data/logs/postgres_out.log
redirect_stderr=true
stopsignal=QUIT
So now, I can start PostgreSQL in supervisorctl by doing start postgres, which runs fine. However, after I issue stop postgres, although supervisorctl declares postgres is stopped, the server apparently is still running as I can psql into it.
I wonder if this is a Supervisor config issue, or a PostgreSQL issue. Any suggestion welcome!
The blog post is rather badly written. There is no "TCP mode": the post's suggested method will still listen on a Unix socket, just in a different directory. Comments in the post such as "external pid file - not needed for TCP mode" are very misleading.
postmaster is the traditional name for the postgresql executable (to distinguish the master dispatching process from the backend slaves). For some time now there has been no separate executable, and now it is installed as simply "postgres".
Assuming that Supervisor is broadly simliar to the qmail/daemontools supervise scheme, it would be entirely possible (in fact, quite normal) to have it run a script that sets up the directories and environment, and then execs postgres with the requisite arguments (or propagates arguments given to the wrapper script, which would be unusual with supervise but makes more sense when you have a config file to put arguments into).
The way supervise worked (and I'm going to continue to assume "Supervisor" is the same) is to have the supervisor process run a subprocess as specified, and simply relaunch a new subprocess if it exits. This is based on the idea that the process being launched is a long-lived daemon process that only exits when something goes badly wrong, and that simply restarting it is a valid fix. By contrast, init scripts such as in /etc/init.d run the subprocess and detach it, and return control to their caller- if the subprocess exits, nothing special happens, and it must be restarted manually. If you tried to simply run /etc/init.d/postgresql start from supervise, it would continuously keep spawning postgresql daemons, as the return from the init script would be interpreted as the daemon process having exited, when in fact it had been started and detached.
To avoid auto-starting the service with the /etc/init.d scripts, the package for postgresql 9.1 provides a file /etc/postgresql/9.1/main/start.conf that contains:
# Automatic startup configuration
# auto: automatically start/stop the cluster in the init script
# manual: do not start/stop in init scripts, but allow manual startup with
# pg_ctlcluster
# disabled: do not allow manual startup with pg_ctlcluster (this can be easily
# circumvented and is only meant to be a small protection for
# accidents).
auto
This is the file to modify to avoid auto-start as opposed to moving away /etc/init.d/postgresql as the blog post suggests.
Also, changing unix sockets parameters for lack of /var/run/postgresql doesn't look like the best idea, because it's the default for any program linked with libpq, and because there's no difficulty in creating that directory with the proper permissions, just like it's done by the package's start sequence in /usr/share/postgresql-common/init.d-functions:
# create socket directory
if [ -d /var/run/postgresql ]; then
chmod 2775 /var/run/postgresql
else
install -d -m 2775 -o postgres -g postgres /var/run/postgresql
fi
And although the default value shouldn't cause a problem, note that whether postmaster ultimately stays in foreground or forks and runs in background is controlled by the silent_mode parameter in postgresql.conf. Make sure that it is off.
I am trying to make both tomcat and postgres run under supervisor, and found some hints here : https://serverfault.com/questions/425132/controlling-tomcat-with-supervisor
Here is my modified run_postgresql.sh, using bash :
#!/bin/bash
# This script is run by Supervisor to start PostgreSQL 9.1 in foreground mode
function shutdown()
{
echo "Shutting down PostgreSQL"
pkill postgres
}
if [ -d /var/run/postgresql ]; then
chmod 2775 /var/run/postgresql
else
install -d -m 2775 -o postgres -g postgres /var/run/postgresql
fi
# Allow any signal which would kill a process to stop PostgreSQL
trap shutdown HUP INT QUIT ABRT KILL ALRM TERM TSTP
exec sudo -u postgres /usr/lib/postgresql/9.1/bin/postgres -D /var/lib/postgresql/9.1/main --config-file=/etc/postgresql/9.1/main/postgresql.conf
With this script postgresql stops correctly after supervisorctl stop postgres.