pgexperts / handyrep Goto Github PK

Please shrink the text for the action options (i.e. cluster status, read log, etc.) and enlarge the text for the data itself. Currently the data text is very small and one has to scroll to find it.

need an HAproxy connection plugin.

Servers --> current replica --> manual_failover
Type the name of the replica into the "newmaster" blank.
get 404. The REST function was not activated.
I suspect that the wrong parameter ("servername" instead of "newmaster") may be getting passed.

Implement integration with pacemaker for pgbouncer/handyrep failover.

This is a for me. We need docs for the sample GUI.

read_log_lines currently returns a JSON array. These need to be displayed as lines so that the user can read them, one line per array item, probably with a

between.

Currently, if HR goes down before the replication master does, or between the last check on the replication master and the time that HR comes back up, HR will be unable to decide whether it is safe to fail over and will not do so with some timings. This is probably the safest route for now, but we should address it in the future in order to cope with "network down" events.

For items which take defaults, please prefill the defaults in the text blank.

Implement support for cascading replication. This would involve:

(a) tracking which server each replica cascades from;
(b) polling that server's pg_stat_replication instead of the master's
(c) auto-remaster when the intermediate master-replica goes down

What are the plans to containerize handyrep with Docker? Do you plan to accept PRs for it here?

Currently the status bar at the top seems to only refresh if you change servers. This leads to some odd views if, for example, you just called poll() and you expect to see the results of that poll reflected in status changes.

The status frame should refresh a lot. It's cheap.

HandyrepGUI needs a "logout" button or link.

Implement support for synchronous replication. This would involve:

• Tracking which servers are sync replicas
• Altering pg.conf for the master to change sync replica config (probably done with include files or conf.d)
• Offering a timeout for sync replica being down, so that we reset the master as non-sync.

Kacey,

Check the API docs for these. I added them after your first cut at a UI.

So, I'd like to overhaul how GUI navigation works. The way I imagine it is:

1. User logs in to the Handyrep Server.
2. get_status?cached results are displayed.
3. Server names are clickable.
4. If a server name is clicked, you get get_server_info for that server, plus a list of actions for that server (see below for actions)
5. Any time the user migrates back to the home page, they get the get_status.

We'd still need navigation for items which have nothing to do with a particular server, probably something like what we have now.

Actions based on server role in a comment once I get done filing other issues.

The base URL should redirect to get_status() on the flask app. Not quite sure how to do this.

Provide a handyrep.conf option which disables recording servers.save to a table in the database, for dead-simple two-server configurations.

Kacey:

http://gui.john.handyrep.org/action/clone/

... gets a python error. Not sure what's broken.

1. Try to disable the current replica, get:
   Error: Undefined argument: clonefrom
   ... clonefrom is not an argument for disable.
2. Try to clone a replica, with replicaserver={name}, reclone=True

first, the options presented to the user are wrong. they are:

replicaserver
The new replica to clone to.
Please enter your choice:
reclone
Whether to clone over an existing replica, if any. If set to False (the default), clone will abort if this server has an operational PostgreSQL on it.

replicaserver should be automatically populated based on which server the user is looking at. However, "clonefrom" should not be populated, and should be presented as an option to the user.

Handyrep should have a seperate initialization command, as well as the resync command. This would be different from resync in the following ways:

1. It would create the directories it needs (such as wal_archive) if they are not already present.
2. if run on the replica, it would check that all symlink targets on the master exist on the standby, and error out if they don't before attempting to sync.
3. it would create handyrep/recovery.conf template based on information in handyrep.conf.
4. it would copy the master database, possibly using a different method than resync does (such as pg_basebackup instead of rsync).

This is a Chippy request.

As discussed on IRC:
using the clone, reclone=True in the GUI returns a 404 regardless of what happens on the server. Due to other stuff, I suspect that the parameters aren't being bassed to the rest interface.

/verify_server, params={'server': u''} returns:
{u'Error': u'Undefined function verify_server'}

The subtitle under the logo isn't working for me; can we have just the plain HR logo?

Christophe,

reload_conf takes a file path as a parameter. However, this blows up the rest UI; it errors out because of the slashes in the file path. Canonical Flask advice is to use a path variable instead of a string variable, but this would require pretty significant surgery to hdaemon to make it work. Simpler fixes?

We need a clone_rsync plugin as well, which should handle all of the steps required for creating a new replica via start backup, rsync, and stop backup. Should also check that archiving is set up before starting.

/poll_master returns:
{u'Error': u'Undefined function poll_master'}
The API does not suggest that this is unavailable to through the Web API.

We need to support other types of authentication, rather than just an admin and RO password. These would include:

LDAP/AD
PAM
DB Table

This will require:
Moving the authenticate() function to a plugin
writing several plugins

Add configuration option and function call to have handyrep push a postgresql.conf include to all servers. In this case, all replication options would be managed from a handyrep template, and would be pushed to handyrep.conf on each machine.

Right now, in status results, the host names are top-level tags along with other, keyword tags like "result". This is probably a bad idea, since inevitably there will be a conflict.

I'd suggest having a top-level tag called something like "hosts", whose value is a dict of "hostname": status pairs.

In particular, we need to distinguish between the case where we know that the master has shutdown cleanly and we can continue with the same backup series, and the case where we don't know that and so we need to start a new backup series.

For the features which just spit out JSON and we don't do much with in the GUI, we should at least format the JSON output. Maybe something like this? https://github.com/warfares/pretty-json

Need to add a bunch more logging hooks for when verbose logging has been enabled.

See title.

When running pg_resync_replica, we should check that pitr-hosts.conf (or handyrep-hosts.conf) is identical on the master server and the current replica. If not, the script should abort.

This is a Chippy request.

If servers.save file is corrupted, HR should skip it and move on. Right now it aborts.

Same with contents of handyrep table, now that I think about it.

Commit: 15e69db

Seems to have syntax errors in daemon/daemonfunctions.py and lib/config.py

One reason HR can be unavailable is if you accidentally try to start two instances of HR on the same server. However, if you do that, the REST interface (and the GUI) don't work. So, how does the user retrieve the error message that that's the problem?