Thread: BDR setup - bdr_node_join_wait_for_ready()
What exactly does bdr_node_wait_for_ready() do? I've been trying to setup BDR on an existing database and once I run the select bdr.bdr_node_wait_for_ready(); command on the 2nd node after running the bdr.bdr_group_join() command it just hangs . I've done the same setup procedure on brand new nodes and have no issue with this command and BDR works fine. Is there anything that can be done to insure this command executes properly on an existing database? Thanks you in advance! Carter -- View this message in context: http://postgresql.nabble.com/BDR-setup-bdr-node-join-wait-for-ready-tp5863606.html Sent from the PostgreSQL - general mailing list archive at Nabble.com.
El 27/08/15 a las 13:35, cchee-ob escribió:
> What exactly does bdr_node_wait_for_ready() do? I've been trying to setup
> BDR on an existing database and once I run the select
> bdr.bdr_node_wait_for_ready(); command on the 2nd node after running the
> bdr.bdr_group_join() command it just hangs . I've done the same setup
> procedure on brand new nodes and have no issue with this command and BDR
> works fine. Is there anything that can be done to insure this command
> executes properly on an existing database?
The funtion is called bdr.bdr_node_join_wait_for_ready(), but I suppose
that's just a mistake when writing this mail.
As long as the node is still joining with the bdr group,
bdr.bdr_node_join_wait_for_ready() will not end.
It basically checks the node_status on bdr.bdr_nodes:
CREATE FUNCTION bdr.bdr_node_join_wait_for_ready()
RETURNS void LANGUAGE plpgsql VOLATILE AS $body$
DECLARE
_node_status "char";
BEGIN
IF current_setting('transaction_isolation') <> 'read committed' THEN
RAISE EXCEPTION 'Can only wait for node join in an ISOLATION
LEVEL READ COMMITTED transaction, not %',
current_setting('transaction_isolation');
END IF;
LOOP
SELECT INTO _node_status
node_status
FROM bdr.bdr_nodes
WHERE (node_sysid, node_timeline, node_dboid)
= bdr.bdr_get_local_nodeid();
PERFORM pg_sleep(0.5);
EXIT WHEN _node_status = 'r';
END LOOP;
END;
$body$;
BTW, why don't you the physical join procedure with bdr_init_copy to
join nodes?
Regards,
--
Martín Marqués http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
Hello all, Le 31/08/2015 02:25, Martín Marqués a écrit : > BTW, why don't you the physical join procedure with bdr_init_copy to > join nodes? Are there known problems in the SQL interface ? Thank you, Sylvain
On 28 August 2015 at 00:35, cchee-ob <carter.chee@objectbrains.com> wrote: > What exactly does bdr_node_wait_for_ready() do? I've been trying to setup > BDR on an existing database and once I run the select > bdr.bdr_node_wait_for_ready(); command on the 2nd node after running the > bdr.bdr_group_join() command it just hangs . I've done the same setup > procedure on brand new nodes and have no issue with this command and BDR > works fine. Is there anything that can be done to insure this command > executes properly on an existing database? Check the PostgreSQL logs on the node(s). The wait for ready function does just that - it waits. If the node never joins properly and never reaches the ready state, it'll wait indefinitely. There is presumably an issue with the node joining. To learn more you'll need to take a look at the log files. We cannot, unfortunately, have bdr_node_join wait until the join completes, because it's necessary to co-ordinate with background workers, commit multiple transactions, etc. It's not clear from your description what you mean by "on an existing database". Details? -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
I have not used the bdr_init_copy procedure because I've haven't been able to find any step by step documentation on how to use. Can you provide some? -- View this message in context: http://postgresql.nabble.com/BDR-setup-bdr-node-join-wait-for-ready-tp5863606p5864210.html Sent from the PostgreSQL - general mailing list archive at Nabble.com.
Craig, By an existing database, I mean I have a database that has our data on it. I have created the btree_gist and bdr extensions and ran the bdr.bdr_group_create () function and the bdr.bdr_node_join_wait_for_ready(), all run successfully. After setting up the next BDR node, and after running bdr.bdr_group_join() function I run the bdr.bdr_node_join_wait_for_ready() function it just sits there and nothing returns. It doesn't look like it's replicating data either. But if I create both BDR nodes without any data in the 1st node they create fine and I can import the database from the export and the data will be in both nodes. Any insight into why this might occur? What is the best practice for creating a BDR environment with 2 BDR nodes and 1 UDR node? Carter -- View this message in context: http://postgresql.nabble.com/BDR-setup-bdr-node-join-wait-for-ready-tp5863606p5864213.html Sent from the PostgreSQL - general mailing list archive at Nabble.com.
On 2 September 2015 at 00:12, cchee-ob <carter.chee@objectbrains.com> wrote: > Craig, > > By an existing database, I mean I have a database that has our data on it. > I have created the btree_gist and bdr extensions and ran the > bdr.bdr_group_create () function and the bdr.bdr_node_join_wait_for_ready(), > all run successfully. After setting up the next BDR node, and after running > bdr.bdr_group_join() function I run the bdr.bdr_node_join_wait_for_ready() > function it just sits there and nothing returns. It doesn't look like it's > replicating data either. As I said above, please check the PostgreSQL logs on both nodes. That should generally be more informative. Also please show the output of select * from bdr.bdr_nodes from both nodes. The database for the 2nd node you were joining should've been completely blank before you tried to join it. Was it? Try CREATE DATABASE ... TEMPLATE template0; to make sure. > What is the best practice for creating a BDR environment with 2 BDR nodes > and 1 UDR node? At this time UDR and BDR don't mix especially well. It's something we're working to address, but is lower priority than getting more of the underlying functionality into PostgreSQL 9.6 and streamlining the user experience. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services