Can't DROP DATABASE or DROP EXTENSION even after parting a node, or on the last node #127

Closed
ringerc opened this Issue Sep 21, 2015 · 3 comments

Comments

Projects
None yet
2 participants
@ringerc
Member

ringerc commented Sep 21, 2015

We don't have a way to cleanly shut down BDR and remove it on a node.

Here's the manual process, in the mean time.

BEGIN;
SET LOCAL bdr.skip_ddl_locking = on;
SET LOCAL bdr.permit_unsafe_ddl_commands = on;
SET LOCAL bdr.skip_ddl_replication = on;
SECURITY LABEL FOR bdr ON DATABASE mydb IS NULL;
DELETE FROM bdr.bdr_connections;
DELETE FROM bdr.bdr_nodes;
SELECT bdr.bdr_connections_changed();
COMMIT;

SELECT pg_terminate_backend(pid)
FROM pg_stat_activity
WHERE datname = current_database() AND application_name LIKE '%): perdb';

DROP EXTENSION bdr;

... then remove 'bdr' from shared_preload_libraries.

@ringerc ringerc added this to the future milestone Sep 21, 2015

@ringerc

This comment has been minimized.

Show comment
Hide comment
@ringerc

ringerc Oct 20, 2015

Member

The right way to do this is probably in the perdb worker, in bdr_maintain_db_workers(), by detecting when we've terminated all the active workers and dropped all slots. Then drop the security label and change the node state.

Member

ringerc commented Oct 20, 2015

The right way to do this is probably in the perdb worker, in bdr_maintain_db_workers(), by detecting when we've terminated all the active workers and dropped all slots. Then drop the security label and change the node state.

@ringerc

This comment has been minimized.

Show comment
Hide comment
@ringerc

ringerc Oct 21, 2015

Member

Bumped from 0.9.3; doing this right looks like it requires the addition of a "parted" state too, and it was going to require more testing than I had time for.

In production deployments it's typical to just destroy the whole PostgreSQL install when you part a node, if not the whole (usually virtual) machine. So it hasn't been a concern that it's fiddly to manually "de-BDR-ize" a database to date.

Member

ringerc commented Oct 21, 2015

Bumped from 0.9.3; doing this right looks like it requires the addition of a "parted" state too, and it was going to require more testing than I had time for.

In production deployments it's typical to just destroy the whole PostgreSQL install when you part a node, if not the whole (usually virtual) machine. So it hasn't been a concern that it's fiddly to manually "de-BDR-ize" a database to date.

@jstuhli

This comment has been minimized.

Show comment
Hide comment
@jstuhli

jstuhli Jun 2, 2016

After doing this I'm stuck with:

2016-06-02 07:20:28 UTC LOG: starting background worker process "bdr db: mydb"
2016-06-02 07:20:28 UTC ERROR: bdr extension is not installed in the current database
2016-06-02 07:20:28 UTC LOG: worker process: bdr db: mydb (PID 2213) exited with exit code 1

If I remove 'bdr' from shared_preload_libraries the errors go away, however I would like to start with a clean slate and setup UDR from scratch.
Is there a way to remove everything bdr related from my cluster, and to reinstall it?

jstuhli commented Jun 2, 2016

After doing this I'm stuck with:

2016-06-02 07:20:28 UTC LOG: starting background worker process "bdr db: mydb"
2016-06-02 07:20:28 UTC ERROR: bdr extension is not installed in the current database
2016-06-02 07:20:28 UTC LOG: worker process: bdr db: mydb (PID 2213) exited with exit code 1

If I remove 'bdr' from shared_preload_libraries the errors go away, however I would like to start with a clean slate and setup UDR from scratch.
Is there a way to remove everything bdr related from my cluster, and to reinstall it?

@ringerc ringerc closed this in cf8f84c Jul 25, 2016

ringerc added a commit that referenced this issue Jul 29, 2016

Add a function to completely remove BDR from a node
Add bdr.remove_bdr_from_local_node() function to remove BDR from a
node. Fixes #127.

@ringerc ringerc changed the title from Can't DROP DATABASE even after parting a node, or on the last node to Can't DROP DATABASE or DROP EXTENSION even after parting a node, or on the last node Sep 12, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment