This article is part of the PoWA 4 beta series, and describes the new powa-collector daemon.

New powa-collector daemon

This daemon replaces the previous background worker when using the new remote mode. It’s a simple daemon written in python, which will perform all the required steps to perform remote snapshots. It’s available on pypi.

As I explained in my previous article introducing PoWA 4, this daemon is required for a remote mode setup, with this architecture in mind:

Its configuration is very simple. All you need to do is copy and rename the provided powa-collector.conf.sample file, and adapt the connection URI to describe how to connect on your dedicated repository server, and you’re done.

A typical configuration will look like:

{
    "repository": {
        "dsn": "postgresql://powa_user@server_dns:5432/powa",
    },
    "debug": true
}

The list of remote servers, their configuration and everything else it needs will be automatically retrieved from the repository server you just configured. When started, it’ll spawn one dedicated thread per declared remote server, and maintain a persistent connection on the configured powa database on this remote server. Each thread will perform a remote snapshot, exporting the data on the repository server using the new source functions. Each thread will open and close a connection on the repository server when performing the remote snapshot.

This daemon obviously needs to be able to connect to all the declared remote servers and the repository server. The powa_servers table, which store the list of remote servers, has a field to store username and password to connect to the remote server. Storing a password in plain text in this table is an heresy as far as security is concerned. So, as mentioned in the PoWA security documentation, you can store a NULL password and instead use any of the authentication method that libpq supports (.pgpass file, certificate…). That’s strongly recommended for any non toy setup.

The persistent connection on the repository server is used to monitor the daemon:

• to check that the daemon is up and running
• to communicate through the UI using a simple protocol to perform various actions (reload the configuration, check for a remote server thread status…)

Note that you can also ask the daemon to reload its configuration by issuing a SIGHUP to the daemon process. A reload is required if any modification to the list of remote servers (if you added or removed a remote server, or updated a setting for an existing) has been done.

Also note that by choice, powa-collector will not perform local snapshots. If you want to use PoWA for the repository server, you need to enable the original background worker.

New configuration page

The configuration page is now updated to give all needed information about the background worker status and the powa-collector daemon status (including all of its dedicated threads) and the list of registered remote servers. Here’s an example of the new root configuration page:

If the powa-collector daemon is used, each remote server status will be retrieved using the communication protocol. If the collector encountered any error (connecting to a remote server, during a snapshot or anything else), they’ll also be displayed here. Also note that such errors will also be displayed on top of any page of the UI, so that you can’t miss them.

Also, the configuration section has now a hierarchy, and you’ll be able to see the list of extensions and the current PostgreSQL configuration for the local or remote servers by clicking on the server of your choice!

There’s also a new Reload collector button on the header panel, which as expected will ask the collector to reload its configuration. That can be useful if you registered new servers and you don’t have access on the server where the collector is running.

Conclusion

This is the last article introducing the new version of PoWA. It’s still in beta, so feel free to test it, report any issue you may find or give any other feedback!