Comment 1 for bug 2047764

start_vault(...) looks like this:

@when_not("is-update-status-hook")
@when('configured')
@when_not('started')
def start_vault():
    # start or restart vault
    vault.opportunistic_restart()

    @tenacity.retry(wait=tenacity.wait_exponential(multiplier=1, max=10),
                    stop=tenacity.stop_after_attempt(10),
                    retry=tenacity.retry_if_result(lambda b: not b))
    def _check_vault_running():
        return service_running('vault')

    if _check_vault_running():
        set_flag('started')
        clear_flag('failed.to.start')
        if config('totally-unsecure-auto-unlock'):
            vault.prepare_vault()
    else:
        set_flag('failed.to.start')

It's probable that opportunistic_restart() is trying very hard not to restart the vault unit as that will seal it. This is because opportunistic_restart() -> can_restart() won't return True if the vault unit is unsealed, which it probably is if the vault unit is running.

A solution is to pause the unit (using the action), then un-pause it (again using the resume action) and then unseal the unit. This will cause the unit to use the new db configured.

As to solving this, the charm should probably stop the service when the shared-db relation is broken, but obviously, removing shared_db causes the charm to fall back to raft as the consensus system. Hmm