[HACKERS] Synchronous replication: Promotion of Standby to Primary
Hi, Re-opening the discussion related to triggers to promote standby server. In the earlier dicussion, there were 2 proposals, Trigger based on file and trigger based on signals. I think there was no conclusion on this. http://archives.postgresql.org/pgsql-hackers/2008-12/msg01231.php According to the proposal, it seems to be better if signals are used as we can avoid checking the file existance in the loop. Or the other approach is to use inotify (http://en.wikipedia.org/wiki/Inotify). But portability to other unix like OS is an issue to look for. Could you please get back which is being implemented/ considered for promotion of standby? regards, Niranjan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Synchronous replication: replication_timeout parameter
Hi, This is with respect to the planned GUC parameter 'replication_timeout' which used in context with 'replication_timeout_action' parameter. http://archives.postgresql.org/pgsql-hackers/2008-12/msg01231.php Here the proposal is to use the milliseconds as the unit for the 'replication_timeout'. The client applications based on the type of transactions ie if the applications support very large transactions and if it uses low-end HW configurations for replication, then it need to configure this parameter correctly to avoid unneccessary timeouts. Are there any ideas already implemented in this front? Also are there any possible conflicts because of inclusion of this parameter? regards, Niranjan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Synchronous replication: Admin command for replication_timeout_action
Hi, This is to support an admin command or utility which can trigger the server to be taken to a standalone mode if there a connection failure detection between Primary and server. It need not be always, that the replication_timeout needs to be accomplished to detect the connection failure because it could happen that cluster/hearbeat framework might detect the connection failure earlier to the replication_timeout. So the admin command, which will abstract the implementation details will assist in taking the server to standalone mode earlier to replication_timeout. Are there any suggestions from your side with respect to this? regards, Niranjan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Synchronous replication: psqlODBC driver compilation
Hi, Upon applying synchronous replication patch and subsequent compilation of psqlODBC sources will lead to compilation errors. As a workaround users can compile the psqlODBC sources using the mainstream postgres source tree and then apply the sync rep patch. But this restriction will need to be removed as the users will expect successful compilation of psqlODBC with or without synchronous replication patch. regards, Niranjan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Synch Replication: Synchronization of files between Primary Standby
Hi, Starting a new thread related to synchronization of the data files, WAL etc.. between Primary and standby servers in Synchronous replication patch. Use case: Whenever the primary and standby are out of sync due to network problems. Existing handling is to prepare the standby by 1) Deleting the $PGDATA on standby 2) Make a fresh base backup of the primary and load this data to the standby 3) Setup the necessary configurations (ex. recovery) and start the standby server In the earlier discussions, please check the link (point 2 related to direct connection between primary and standby), i think we still need to work to conclude on what will be done. http://archives.postgresql.org/pgsql-hackers/2009-02/msg01160.php One issue to be addressed is also the usability aspect of the solution for the mentioned use case. For synchronization of files with direct connection, there were suggestions to consider VLDB cases too. Do you already have some ideas which is getting implemented? We can kick start the discussion so as to conclude on the possible solution. Regards, Niranjan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Sync replication tests
Hi, Steps to re-produce the sync replication bug: - Setup the Primary server and standby server - Don't execute any transactions on the Primary server - Initiate a switchover by creating a finish.trigger on the Standby server - The standby server (the startup process) will terminate with SIGABRT signal and no connection to the Database will be possible after that. regards, Niranjan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Synchronous replication Hot standby patches
Hi, Could you please let me know what are the outstanding features that are still to be developed in the respective patches? I'am currently referring the wiki: Todo and Claim for NTT and for HotStandby, i see that almost all issues are closed. Are there any features / refactoring / bugs still need to be fixed. Thanks, Niranjan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Synch Replication
Hi, Thanks. Now it works. Few questions: 1) Do you have an idea by when the Hot standby patch and Sync replication patch will be integrated? 2) I have used 1 physical machine to try current patch of synchronous replication. Is it OK for me to try with 2 separate machines for Primary Standby servers 3) Do you have test programs that can used for synchronous replication testing? 4) I'am thinking of trying load/performance tests as well. What do you feel? Will it be too early to do this test? regards, Niranjan -Original Message- From: ext Fujii Masao [mailto:masao.fu...@gmail.com] Sent: Monday, February 09, 2009 7:47 PM To: K, Niranjan (NSN - IN/Bangalore) Cc: PostgreSQL-development Subject: Re: Synch Replication Hi Niranjan, On Mon, Feb 9, 2009 at 10:39 PM, K, Niranjan (NSN - IN/Bangalore) niranja...@nsn.com wrote: But after I login to replication database (note the active I had brought it down earlier created a finish.trigger), I still cannot see the table that was created on the primary. Also please note that the LSN had changed after replication in the ps command. Did you create the table in 'replication' database? If not, please connect to the correct database which includes the table. In log-shipping, the database objects are basically identical between the primary and the standby server. Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Synch Replication
Hi,
Thanks for the response.
I tried with the your sources and found the same issue.
I explain the steps that I followed, just to avoid any gaps in
understanding.
1) I assumes that the patch was already applied in your sources. So did
went ahead doing configure, make and make install
2) Built pg_standby and copied manually to postgres bin directory
3) Copied the test_sync_repl.sh in postgres directory
4) Run the script. Refer startup.log. Also verified the walsender and
walreceiver processes are running. Refer ps.log.
Tests done:
1) Execute psql -l. Refer list_database.log
2) Login to standby with command psql -d replication and execute SQL
select * from pg_roles;. This worked fine.
3) Login to primary with command psql -d postgres and execute SQL
create table temp1 (int int);. On execution of this query the standby
instance came down. Refer createTable.log (printed on console)
One of the hacker suggested to remove the echo host all all 0.0.0.0/0
trust ${SBYDATA}/pg_hba.conf for standby database only. But here
too the result was same.
Environment that I use:
- RHEL 4.7
- Both Primary standby in the same machine
Could you please help. If you need any more symptoms, I can re-work.
Thanks,
Niranjan
-Original Message-
From: ext Fujii Masao [mailto:masao.fu...@gmail.com]
Sent: Wednesday, February 04, 2009 7:05 AM
To: K, Niranjan (NSN - IN/Bangalore)
Cc: PostgreSQL-development
Subject: Re: Synch Replication
Hi,
Ooops, my mail client has sent the previous message, on the
way. Sorry.
On Wed, Feb 4, 2009 at 10:24 AM, Fujii Masao
masao.fu...@gmail.com wrote:
Hi,
Thanks for your testing and report!
On Tue, Feb 3, 2009 at 8:18 PM, K, Niranjan (NSN - IN/Bangalore)
niranja...@nsn.com wrote:
Hi,
I tried using the Synchronous replication and I'am unable to
replicate the queries (Ex. create table temp1(int int);).
I have downloaded the latest postgres dev snapshot and the latest
sync replication patch from wiki.
I have attached the log file which has the trace
statements displayed
on the console. I actually changed the
'test_synch_rep.sh', so that
the standby database will put detailed trace messages.
I'am actaully getting error related to history file.
Could you please help regarding this.
The problem which you pointed out was not reproduced on my machine.
I suspect that the base HEAD version might be different between us.
I uploaded my pgsql source with synch rep patch (v0128), so
please try it.
http://senduit.com/e5a942
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source
Software Center
startup.log
Description: startup.log
ps.log
Description: ps.log
list_database.log
Description: list_database.log
createTable.log
Description: createTable.log
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Synch Replication
- Do you use a packet filtering software (eg. firewall)? If yes, what happens if you disabled such a software? Firewall was disabled - Do you use SELinux? If yes, what happens if you disabled SELinux? SELinux is disabled. - Please run the following commands and report those results. * uname -a * pg_config Please see the logs attached. Thanks, Niranjan pg_config.log Description: pg_config.log uname.log Description: uname.log -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Postgres-R
Unfortunately, I'am getting the error as below when I start the gossip. I had
followed the same steps as you mentioned.
REFLECT:I'm not in the list of gossip hosts, exiting
(the hosts are [cluster_1|cluster_2])
cluster_1 cluster_2 are node names are the in /etc/hosts.
Did you face this?
regards,
Niranjan
-Original Message-
From: ext leiyonghua [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 19, 2008 6:42 AM
To: K, Niranjan (NSN - IN/Bangalore)
Cc: Markus Wanner; pgsql-hackers@postgresql.org
Subject: Re: Postgres-R
hi,
Assume that we have two node
node 0 , 192.168.0.2
node 1 , 192.168.0.3
1. add a host entry in /etc/hosts for hostname resolving.
2. add the host list in configuration 'ensemble.conf' for gossip service:
ENS_GOSSIP_HOSTS=node0:node1
3. set the envrionment variable ENS_CONFIG_FILE export
ENS_CONFIG_FILE=/xxx/xxx/ensemble.conf
4. start ensemble gossip
5. try 'c_mtalk' and happy.
this is a simplest case for me, hehe!
leiyonghua
K, Niranjan (NSN - IN/Bangalore) 写道:
Thanks for the information.
For Step5 (starting ensemble daemon).- I set the multicast address to
both nodes (Node 1 Node 2 eth0: 224.0.0.9/4) before starting the ensemble.
And started the server application mtalk in node 1 node 2 and then client
application in node 1 node 2. But the count of members ('nmembers') show as
1. This is the output of the client program 'c_mtalk'. Seeing this, I'am
assuming that the applications are not merged.
Could you please let me know how did you proceed with the setup of ensemble?
regards,
Niranjan
-Original Message-
From: ext leiyonghua [mailto:[EMAIL PROTECTED]
Sent: Monday, August 18, 2008 2:58 PM
To: K, Niranjan (NSN - IN/Bangalore); Markus Wanner;
pgsql-hackers@postgresql.org
Subject: Re: Postgres-R
[EMAIL PROTECTED] 写道:
I wish to set up the Postgres-R environment, could you please let me know
the steps for setting it up.
Thanks.
yeah, actually, i have not been successful to set up this, but let me give
some information for you.
1. download the postgresql snapshot source code from here:
http://www.postgresql.org/ftp/snapshot/dev/
(this is a daily tarball)
2. Get the corresponding patch for postgres-r from:
http://www.postgres-r.org/downloads/
3. apply the patch for snapshot source, and configure like this:
./configure --enable-replication
make make install
4. install the GCS ensemble, according the document :
http://www.cs.technion.ac.il/dsl/projects/Ensemble/doc.html
5. start ensemble daemon and gossip if neccessary ( yes, make sure the
two nodes can 'GCS' each other)
3. Assume that you have two nodes, start up postgresql and create a database
'db', and create a table 'tb' for testing which should be have a primary key
for all nodes.
4. At the origin node, execute the command at psql console:
alter database db start replication in group gcs; (which means the
database 'db' is the origin and the group 'gcs' is the GCS group name)
5. At the subscriber node, execute the command:
alter database db accept replication from group gcs;
Hope information above would be helpful, and keep in touch.
leiyonghua
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Postgres-R
Thanks for the information.
For Step5 (starting ensemble daemon).-
I set the multicast address to both nodes (Node 1 Node 2 eth0: 224.0.0.9/4)
before starting the ensemble. And started the server application mtalk in node
1 node 2 and then client application in node 1 node 2. But the count of
members ('nmembers') show as 1. This is the output of the client program
'c_mtalk'. Seeing this, I'am assuming that the applications are not merged.
Could you please let me know how did you proceed with the setup of ensemble?
regards,
Niranjan
-Original Message-
From: ext leiyonghua [mailto:[EMAIL PROTECTED]
Sent: Monday, August 18, 2008 2:58 PM
To: K, Niranjan (NSN - IN/Bangalore); Markus Wanner;
pgsql-hackers@postgresql.org
Subject: Re: Postgres-R
[EMAIL PROTECTED] 写道:
I wish to set up the Postgres-R environment, could you please let me know the
steps for setting it up.
Thanks.
yeah, actually, i have not been successful to set up this, but let me give some
information for you.
1. download the postgresql snapshot source code from here:
http://www.postgresql.org/ftp/snapshot/dev/
(this is a daily tarball)
2. Get the corresponding patch for postgres-r from:
http://www.postgres-r.org/downloads/
3. apply the patch for snapshot source, and configure like this:
./configure --enable-replication
make make install
4. install the GCS ensemble, according the document :
http://www.cs.technion.ac.il/dsl/projects/Ensemble/doc.html
5. start ensemble daemon and gossip if neccessary ( yes, make sure the two
nodes can 'GCS' each other)
3. Assume that you have two nodes, start up postgresql and create a database
'db', and create a table 'tb' for testing which should be have a primary key
for all nodes.
4. At the origin node, execute the command at psql console:
alter database db start replication in group gcs; (which means the database
'db' is the origin and the group 'gcs' is the GCS group name)
5. At the subscriber node, execute the command:
alter database db accept replication from group gcs;
Hope information above would be helpful, and keep in touch.
leiyonghua
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
