7 Commits

Author SHA1 Message Date
Dmitry Simonenko
79f6223631 Replace UserMappings with a connection ID
This change replace UserMappings with newly introduced TSConnectionId
object, which represent a pair of foreign server id and local user id.

Authentication has been moved to non-password based, since original
UserMappings were used to store a data node user passwords as
well. This is a temporary step, until introduction of certificate
based authentication.

List of changes:

* add_data_node() password and bootstrap_password arguments removed

* introduced authentication using pgpass file

* RemoteTxn format string which represents tx changed to
  tx-version-xid-server_id-user_id

* data_node_dispatch, remote transaction cache, connection cache hash
  tables keys switched to TSConnectionId instead of user mappings

* remote_connection_open() been rework to exclude user options

* Tests upgraded, user mappings and passwords usage has been excluded
2020-05-27 17:31:09 +02:00
Erik Nordström
b07461ec00 Refactor and harden data node management
This change refactors and hardens parts of data node management
functionality.

* A number of of permissions checks have been added to data node
  management functions. This includes checking that the user has
  proper permissions for both table and server objects.
* Permissions checks are now done when creating remote chunks on data
  nodes.
* The add_data_node() API function has been simplified and now returns
  more intuitive status about created objects (foreign server,
  database, extension). It is no longer necessary to specify a user to
  connect with as this is always assumed to be the current user. The
  bootstrap user can still be specified explicitly, however, as that
  user might require elevated permissions on the remote node to
  bootstrap.
* Functions that capture exceptions without re-throwing, such as
  `ping_data_node()` and `get_user_mapping()`, have been refactored to
  not do this as the transaction state and memory contexts are not in
  states where it is safe to proceed as normal.
* Data node management functions now consistently check that any
  foreign servers operated on are actually TimescaleDB server objects.
* Tests now run with a superuser a regular user specific to
  clustering. These users have password auth enabled in `pg_hba.conf`,
  which is required by the connection library when connecting as a
  non-superuser. Tests have been refactored to bootstrap data nodes
  using these user roles.
2020-05-27 17:31:09 +02:00
Brian Rowe
79fb46456f Rename server to data node
The timescale clustering code so far has been written referring to the
remote databases as 'servers'.  This terminology is a bit overloaded,
and in particular we don't enforce any network topology limitations
that the term 'server' would suggest.  In light of this we've decided
to change to use the term 'node' when referring to the different
databases in a distributed database.  Specifically we refer to the
frontend as an 'access node' and to the backends as 'data nodes',
though we may omit the access or data qualifier where it's unambiguous.

As the vast bulk of the code so far has been written for the case where
there was a single access node, almost all instances of 'server' were
references to data nodes.  This change has updated the code to rename
those instances.
2020-05-27 17:31:09 +02:00
Brian Rowe
5c643e0ac4 Add distributed group id and enforce topology
This change adds a distributed database id to the installation data for a
database.  It also provides a number of utilities that can be used for
getting/setting/clearing this value or using it to determing if a database is
a frontend, backend, or not a member of distributed database.

This change also includes modifications to the add_server and delete_server
functions to check the distributed id to ensure the operation is allowed, and
then update or clear it appropriately.  After this changes it will no longer
be possible to add a database as a backend to multiple frontend databases, nor
will it be possible to add a frontend database as a backend to any other
database.
2020-05-27 17:31:09 +02:00
Dmitry Simonenko
d8982c3e15 Add add_server() support for remote server bootstrapping
This patch adds functionality for automatic database and extension
creation on remote server. New function arguments: bootstrap_database, bootstrap_user
and bootstrap_password.
2020-05-27 17:31:09 +02:00
Matvey Arye
f5a09913e1 Make heal safe to non-timescale prepared txns
To make the heal function safe to non-ts prepared txns we
introduce a prefix "ts" to our prepared txns. This allows
us to separate cases where there is a ts vs non-ts prepared txn
and have heal ignore non-ts txns.

An alternative would be to consider all txns that don't parse
correctly as non-ts transactions. But, that is less robust to
bugs in our parsing/printing code.

One downside to the current approach is that all prepared txns
with a "ts" prefix are considered reserved for ts. That
should be acceptable.
2020-05-27 17:31:09 +02:00
Matvey Arye
e7ba327f4c Add resolve and heal infrastructure for 2PC
This commit adds the ability to resolve whether or not 2PC
transactions have been committed or aborted and also adds a heal
function to resolve transactions that have been prepared but not
committed or rolled back.

This commit also removes the server id of the primary key on the
remote_txn table and adds another index. This was done because the
`remote_txn_persistent_record_exists` should not rely on the server
being contacted but should rather just check for the existance of the
id. This makes the resolution safe to setups where two frontend server
definitions point to the same database. While this may not be a
properly configured setup, it's better if the resolution process is
robust to this case.
2020-05-27 17:31:09 +02:00