Pg_ctl with postmaster -i option
Hi,
How do configure the pg_ctl program so that when it starts postmaster it wi=
ll start postmaster with the -i option. I want postmaster allows remote u=
ser to connect to the PostgreSQL server.
Thanks in advance
Mary
------------------------------------------------
Mary Y Wang
--
Sent via pgsql-admin mailing list (pgsql-admin [at] postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
Re: Pg_ctl with postmaster -i option
If I understood correctly what you want is to allow remote users or clients=
to connect to your postgresql server
I believe this is controlled by "pg_hba.conf"
Add a line similar to:
host all all 192.168.10.0/24 trust
Renato
Renato Oliveira
Systems Administrator
e-mail: renato.oliveira [at] grant.co.uk
Tel: +44 (0)1763 260811
Fax: +44 (0)1763 262410
http://www.grant.co.uk/
Grant Instruments (Cambridge) Ltd
Company registered in England, registration number 658133
Registered office address:
29 Station Road,
Shepreth,
CAMBS SG8 6GB
UK
-----Original Message-----
From: pgsql-admin-owner [at] postgresql.org [mailto:pgsql-admin-owner [at] postgresql=
..org] On Behalf Of Wang, Mary Y
Sent: 02 February 2010 06:41
To: pgsql-admin [at] postgresql.org
Subject: [ADMIN] Pg_ctl with postmaster -i option
Hi,
How do configure the pg_ctl program so that when it starts postmaster it wi=
ll start postmaster with the -i option. I want postmaster allows remote u=
ser to connect to the PostgreSQL server.
Thanks in advance
Mary
------------------------------------------------
Mary Y Wang
--
Sent via pgsql-admin mailing list (pgsql-admin [at] postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
-----Original Message-----
P Please consider the environment before printing this email
CONFIDENTIALITY: The information in this e-mail and any attachments is conf=
idential. It is intended only for the named recipients(s). If you are not t=
he named recipient please notify the sender immediately and do not disclose=
the contents to another person or take copies.
VIRUSES: The contents of this e-mail or attachment(s) may contain viruses w=
hich could damage your own computer system. Whilst Grant Instruments (Cambr=
idge) Ltd has taken every reasonable precaution to minimise this risk, we c=
annot accept liability for any damage which you sustain as a result of soft=
ware viruses. You should therefore carry out your own virus checks before o=
pening the attachment(s).
OpenXML: For information about the OpenXML file format in use within Grant =
Instruments please visit our http://www.grant.co.uk/Support/openxml.html
--
Sent via pgsql-admin mailing list (pgsql-admin [at] postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
Re: Pg_ctl with postmaster -i option
=46rom $ man postmaster
-i Allows remote clients to connect via TCP/IP (Internet doma=
in)
connections. Without this option, only local connections =
are
accepted. This option is equivalent to setting listen_addres=
ses
to * in postgresql.conf or via -h.
This option is deprecated since it does not allow access to =
the
full functionality of listen_addresses. It's usually better =
to
set listen_addresses directly.
And you will need to set up pg_hba.conf as well, as Renato says. But
maybe more restrictive.
--
Ian.
On Tue, Feb 2, 2010 at 8:36 AM, Renato Oliveira
<renato.oliveira [at] grant.co.uk> wrote:
> If I understood correctly what you want is to allow remote users or clien=
ts to connect to your postgresql server
>
> I believe this is controlled by "pg_hba.conf"
> Add a line similar to:
> host =A0 =A0all =A0 =A0 =A0 =A0 all =A0 =A0 =A0 =A0 192.168.10.0/24 =A0 =
=A0 =A0 trust
>
> Renato
>
>
>
>
> Renato Oliveira
> Systems Administrator
> e-mail: renato.oliveira [at] grant.co.uk
>
> Tel: +44 (0)1763 260811
> Fax: +44 (0)1763 262410
> http://www.grant.co.uk/
>
> Grant Instruments (Cambridge) Ltd
>
> Company registered in England, registration number 658133
>
> Registered office address:
> 29 Station Road,
> Shepreth,
> CAMBS SG8 6GB
> UK
>
> -----Original Message-----
>
>
> From: pgsql-admin-owner [at] postgresql.org [mailto:pgsql-admin-owner [at] postgres=
ql.org] On Behalf Of Wang, Mary Y
> Sent: 02 February 2010 06:41
> To: pgsql-admin [at] postgresql.org
> Subject: [ADMIN] Pg_ctl with postmaster -i option
>
> Hi,
>
> How do configure the pg_ctl program so that when it starts postmaster it =
will start postmaster with the -i option. =A0 I want postmaster allows remo=
te user to connect to the PostgreSQL server.
>
> Thanks in advance
> Mary
>
> ------------------------------------------------
> Mary Y Wang
--
Sent via pgsql-admin mailing list (pgsql-admin [at] postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
PITR clarification to certain points
Dear all,
I apologise for this post in advance, I am sure some of you have already an=
swered many question and maybe find it boring by now.
I have been playing with PITR for some time now and read quite a bit about =
it, it is nice feature. I am really enjoying playing with it.
I have managed to get it working on my test environment, but I have few thi=
ngs I would like mention here in the list and if someone could clarify them=
to me, please it would be very much appreciated.
The Archiving process is very simple and straight and forward
Main Server
1 - You setup postgreSQL
2 - you initialise the cluster: initdb -D /var/lib/pgsql/data
3 - Edit /var/lib/pgsql/data/postgresql.conf and add:
archive_mode =3D on
archive_command =3D 'cp %p /data/pitr/%f'
archive_timeout =3D 600
4 - mkdir /data/pitr; chown postgres: /data/pitr
5 - service postgresql start
6 - select pg_start_backup('/data/pitr');
7 - tar -zcvf data.pitr.tar.gz /var/lib/pgsql/data
8 - select pg_stop_backup();
Everything as far as can think is done for the Primary server, I can see it=
starts working, as soon as I add some data the logs start being archived.
The restore process is not so straight and forward and some it lacks some n=
ecessary info I think
On the StandBy
1 - Install PostgreSQL
2 - initd -D /var/lib/pgsql/data
3 - mv data data.old
4 - tar -zxvf data.pitr.tar.gz
5 - Create a file recovery.conf ad add the following lines:
restore_command =3D 'cp /data/pitr/%f %p'
NOTE if I turn the server on the file recovery.conf is automatically rename=
d to recovery.done and no data other than the original base backup is resto=
red. It does not read the longs copied to /data/pitr and restores them, why=
do you guys think is that?
Then I tried a single server test.
On the Primary Postgre I did.
1 - Killed postgres
2 - moved data to data.afterPITR
3 - restored the base backup
4 - deleted /var/lib/pgsql/data/pg_xlog/* files
5 - deleted /var/lib/pgsql/data/pg_log/*, deleleted PID file
6 - copied /var/lib/pgsql/ data.afterPITR/pg_xlog to /var/lib/pgsql/data/pg=
_log/
7 - created the recovery.conf added:
restore_command =3D 'cp /data/pitr/%f %p'
8 - service start postgresql
Then it worked it did restore to the point I was expecting.
So, this brings me to the following questions:
1 - Do I need to leave the server in recovery mode off, I mean postgresql n=
ot running?
2 - Everytime a disaster strikes, do I need to go back to the base backup a=
nd restore it to the StandBY server?
3 - If point 2 is true, then I would need to do a base backup the other way=
round, for example:
* when primary goes down and I bring the secondary as master fromn =
the recovery process, I need to do a base backup on the secondary which is =
now the primary?
* then when I am restoring the old Primary I need to do the inverse=
process to make it a WARM server?
4 - Which logs really do I need to clean only pg_xlog?
5 - Do I need to copy the old logs from the crashed server from /data/pg_xl=
og to the new master? What about if it has crashed and I can't get anything=
out of it? IS it a 'must' those logs or it is only in case you want to rec=
over to the last minute before it crashed?
6 - Why does it renames the recovery.conf? I thought it would be a continuo=
us process?
I mean I thought the WARM server would be there reading the logs until I te=
ll it otherwise.
Guys I thank all of you in advance for this.
If someone could clarify a bit to me it would be very much appreciated.
Thank you very much
Best regards
Renato
Renato Oliveira
Systems Administrator
e-mail: renato.oliveira [at] grant.co.uk
Tel: +44 (0)1763 260811
Fax: +44 (0)1763 262410
http://www.grant.co.uk/
Grant Instruments (Cambridge) Ltd
Company registered in England, registration number 658133
Registered office address:
29 Station Road,
Shepreth,
CAMBS SG8 6GB
UK
P Please consider the environment before printing this email
CONFIDENTIALITY: The information in this e-mail and any attachments is conf=
idential. It is intended only for the named recipients(s). If you are not t=
he named recipient please notify the sender immediately and do not disclose=
the contents to another person or take copies.
VIRUSES: The contents of this e-mail or attachment(s) may contain viruses w=
hich could damage your own computer system. Whilst Grant Instruments (Cambr=
idge) Ltd has taken every reasonable precaution to minimise this risk, we c=
annot accept liability for any damage which you sustain as a result of soft=
ware viruses. You should therefore carry out your own virus checks before o=
pening the attachment(s).
OpenXML: For information about the OpenXML file format in use within Grant =
Instruments please visit our http://www.grant.co.uk/Support/openxml.html
--
Sent via pgsql-admin mailing list (pgsql-admin [at] postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
Re: PITR clarification to certain points
Guys,
Something I forgotten to point out.
When you do a base backup, you have also the configuration file from the Pr=
imary, which means you will have it configured to archive as well on the WA=
RM server, once you restored it.
So, my guess is I must turn off the archiving process on the WARM? This is =
what I have done!
I have not seen any mention of this in any documentation so far.
Is that correct?
Thank you
Renato
Renato Oliveira
Systems Administrator
e-mail: renato.oliveira [at] grant.co.uk
Tel: +44 (0)1763 260811
Fax: +44 (0)1763 262410
http://www.grant.co.uk/
Grant Instruments (Cambridge) Ltd
Company registered in England, registration number 658133
Registered office address:
29 Station Road,
Shepreth,
CAMBS SG8 6GB
UK
-----Original Message-----
From: pgsql-admin-owner [at] postgresql.org [mailto:pgsql-admin-owner [at] postgresql=
..org] On Behalf Of Renato Oliveira
Sent: 02 February 2010 10:12
To: pgsql-admin [at] postgresql.org
Subject: [ADMIN] PITR clarification to certain points
Importance: High
Dear all,
I apologise for this post in advance, I am sure some of you have already an=
swered many question and maybe find it boring by now.
I have been playing with PITR for some time now and read quite a bit about =
it, it is nice feature. I am really enjoying playing with it.
I have managed to get it working on my test environment, but I have few thi=
ngs I would like mention here in the list and if someone could clarify them=
to me, please it would be very much appreciated.
The Archiving process is very simple and straight and forward
Main Server
1 - You setup postgreSQL
2 - you initialise the cluster: initdb -D /var/lib/pgsql/data
3 - Edit /var/lib/pgsql/data/postgresql.conf and add:
archive_mode =3D on
archive_command =3D 'cp %p /data/pitr/%f'
archive_timeout =3D 600
4 - mkdir /data/pitr; chown postgres: /data/pitr
5 - service postgresql start
6 - select pg_start_backup('/data/pitr');
7 - tar -zcvf data.pitr.tar.gz /var/lib/pgsql/data
8 - select pg_stop_backup();
Everything as far as can think is done for the Primary server, I can see it=
starts working, as soon as I add some data the logs start being archived.
The restore process is not so straight and forward and some it lacks some n=
ecessary info I think
On the StandBy
1 - Install PostgreSQL
2 - initd -D /var/lib/pgsql/data
3 - mv data data.old
4 - tar -zxvf data.pitr.tar.gz
5 - Create a file recovery.conf ad add the following lines:
restore_command =3D 'cp /data/pitr/%f %p'
NOTE if I turn the server on the file recovery.conf is automatically rename=
d to recovery.done and no data other than the original base backup is resto=
red. It does not read the longs copied to /data/pitr and restores them, why=
do you guys think is that?
Then I tried a single server test.
On the Primary Postgre I did.
1 - Killed postgres
2 - moved data to data.afterPITR
3 - restored the base backup
4 - deleted /var/lib/pgsql/data/pg_xlog/* files
5 - deleted /var/lib/pgsql/data/pg_log/*, deleleted PID file
6 - copied /var/lib/pgsql/ data.afterPITR/pg_xlog to /var/lib/pgsql/data/pg=
_log/
7 - created the recovery.conf added:
restore_command =3D 'cp /data/pitr/%f %p'
8 - service start postgresql
Then it worked it did restore to the point I was expecting.
So, this brings me to the following questions:
1 - Do I need to leave the server in recovery mode off, I mean postgresql n=
ot running?
2 - Everytime a disaster strikes, do I need to go back to the base backup a=
nd restore it to the StandBY server?
3 - If point 2 is true, then I would need to do a base backup the other way=
round, for example:
* when primary goes down and I bring the secondary as master fromn =
the recovery process, I need to do a base backup on the secondary which is =
now the primary?
* then when I am restoring the old Primary I need to do the inverse=
process to make it a WARM server?
4 - Which logs really do I need to clean only pg_xlog?
5 - Do I need to copy the old logs from the crashed server from /data/pg_xl=
og to the new master? What about if it has crashed and I can't get anything=
out of it? IS it a 'must' those logs or it is only in case you want to rec=
over to the last minute before it crashed?
6 - Why does it renames the recovery.conf? I thought it would be a continuo=
us process?
I mean I thought the WARM server would be there reading the logs until I te=
ll it otherwise.
Guys I thank all of you in advance for this.
If someone could clarify a bit to me it would be very much appreciated.
Thank you very much
Best regards
Renato
Renato Oliveira
Systems Administrator
e-mail: renato.oliveira [at] grant.co.uk
Tel: +44 (0)1763 260811
Fax: +44 (0)1763 262410
http://www.grant.co.uk/
Grant Instruments (Cambridge) Ltd
Company registered in England, registration number 658133
Registered office address:
29 Station Road,
Shepreth,
CAMBS SG8 6GB
UK
P Please consider the environment before printing this email
CONFIDENTIALITY: The information in this e-mail and any attachments is conf=
idential. It is intended only for the named recipients(s). If you are not t=
he named recipient please notify the sender immediately and do not disclose=
the contents to another person or take copies.
VIRUSES: The contents of this e-mail or attachment(s) may contain viruses w=
hich could damage your own computer system. Whilst Grant Instruments (Cambr=
idge) Ltd has taken every reasonable precaution to minimise this risk, we c=
annot accept liability for any damage which you sustain as a result of soft=
ware viruses. You should therefore carry out your own virus checks before o=
pening the attachment(s).
OpenXML: For information about the OpenXML file format in use within Grant =
Instruments please visit our http://www.grant.co.uk/Support/openxml.html
--
Sent via pgsql-admin mailing list (pgsql-admin [at] postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
-----Original Message-----
P Please consider the environment before printing this email
CONFIDENTIALITY: The information in this e-mail and any attachments is conf=
idential. It is intended only for the named recipients(s). If you are not t=
he named recipient please notify the sender immediately and do not disclose=
the contents to another person or take copies.
VIRUSES: The contents of this e-mail or attachment(s) may contain viruses w=
hich could damage your own computer system. Whilst Grant Instruments (Cambr=
idge) Ltd has taken every reasonable precaution to minimise this risk, we c=
annot accept liability for any damage which you sustain as a result of soft=
ware viruses. You should therefore carry out your own virus checks before o=
pening the attachment(s).
OpenXML: For information about the OpenXML file format in use within Grant =
Instruments please visit our http://www.grant.co.uk/Support/openxml.html
--
Sent via pgsql-admin mailing list (pgsql-admin [at] postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin