Skip to content
This repository has been archived by the owner on Oct 1, 2020. It is now read-only.

creating leaf sets node location incorrectly #25

Open
glenndavy opened this issue Jan 24, 2013 · 7 comments
Open

creating leaf sets node location incorrectly #25

glenndavy opened this issue Jan 24, 2013 · 7 comments

Comments

@glenndavy
Copy link
Contributor

when replicating between 2 boxen, passing a provider connection string that has more than just the dbname, fails to register correctly.

For eg on node2:

londiste3 someini.ini create-leaf node2 dbname=my_clone --provider "dbname=my_master host=db-master user=just_me"

creates a node_location entry on my_clone.pgq_node.node_location for node1 of "dbname=my_master".

Similarly (and I'm not sure at what point) node1 has a node2 entry for node_location of "dbname=my_clone".

In order to get things working, I just manually add a step and update the node_location column with correct db connection details.

I'm happy to drill in a bit and see if I can fix this (good chance to learn some python) and shoot you a pull request, however can you confirm my understanding of how this should work is correct?

@markokr
Copy link
Collaborator

markokr commented Feb 20, 2013

Both of connect strings should have host= also in connect string. Giving connect string without it is usually a bug.
Not always - toy installations in single machine - but on real installaltions its a bug.

So perhaps Londiste should throw error in such cases?

@glenndavy
Copy link
Contributor Author

Hi Markokr, sorry for my delayed response.
well the problem I'm having is not that it doesn't enforce passing in a 'host=' but that when I do pass in a host parameter, it is ignored and so I have to set it my self by updating node_location. So, if the error checking is based on the data written into pgq_node.node_location, not data passed in via --provider, then, yep that works from my pov.

@martinmarques
Copy link

This is an actual issue. Same experience here. Created the leaf with the --provider="dbname=mydb host=myhost" but no host added to the provider.
Maybe tomorrow I can try to get a patch.

@markokr
Copy link
Collaborator

markokr commented Jun 4, 2013

I added error for that case. But then people complained who had testenv in single machine. So I downgraded it to warning:

self.log.warning('No host= in public connect string, bad idea')

Although it could probably be better worded.

@andrewsw-janrain
Copy link
Contributor

seeing this bug too. It's not a matter of whether to warn or not on missing host= in public connection string, but that the public connection string is not faithfully inserted into the database at the time the leaf node is created.

given the following command line:

londiste3 test_slave.ini create-leaf node2 dbname=test --provider="dbname=test host=vm1 user=db_user password=secret"

I expect:

select node_location from pgq.node_location where node_name = 'node1'; 

to return:

dbname=test host=vm1 user=db_user password=secret

but instead it returns just:

dbname=test

and replication fails until I manually fix that up in the database.

edit: note that "node1" is the node name for the provider in the create-leaf call above.

@justizin
Copy link
Contributor

justizin commented Apr 9, 2014

I find it interesting that it's suggested in this thread that skytools should warn on missing host= in the public connection string, while in fact the example configurations all work only on a single machine, leaving all of the interesting not-the-same-machine situations to be resolved by the reader.

@markokr
Copy link
Collaborator

markokr commented Apr 16, 2014

Following improvements are now done:

  • warning on connect string without host=
  • public_node_location= config param, so the connect string does not need to be given on command line.
  • doc/howto/londiste3_simple_rep_howto.txt has host= param in command line examples.

What else should be improved so common user would not get confused?

What else is needed to close this bug?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants