YaXAHA Cluster Configuration
This part covers the YaXAHA Cluster settings. First we have settings that are likely to be useful to new users who are deploying their own cluster.
Next we have the description of yt_info function, that retrieves the current cluster node state and settings, followed by an example of how to find the possible problems while running a cluster.
Before this part, it is recommended to read the YaXAHA Cluster Architecture section.
Failover Settings#
YaXAHA Cluster allows user to specify how many cluster nodes must synchronously repeat the transaction before it is considered successful. The remaining nodes of the cluster can execute the transaction asynchronously.
User can choose between:
- A certain number of nodes
- Half of the cluster nodes
The number of nodes can be set both for the entire cluster and for individual tables.
The cluster determines the boundaries for each transaction and tables that will be changed. Next, the cluster looks for the settings of a particular table, and if the table does not have its own settings, the global cluster settings are applied.
Cluster failover settings exaple:
Rereat transactions synchronously on half of the cluster:
insert into public.yt_config (name, module, value) values ('def_cluster_commit','C','half');
Repeat transactions synchronously at least on two nodes:
insert into public.yt_config (name, module, value) values ('def_cluster_commit','C','nodes>=2');
For a particular table:
update yt_config set value = yt_ct_encode('{"value":{"Table":{"timeout_sec":8,"aggregate_timeout":true,"sequential_consistency":false,"cluster_commit":"half"}}}') where name like '%public.orders' and module = 'A';
PgBouncer#
By default, while installing the yaxaha package, it sets up a patched version of PgBouncer on the node. And we recommend directing the client application requests right through it.
Why PgBouncer?#
PgBouncer as part of YaXAHA Cluster helps to solve several problems:
Connection pool#
In addition to well-known benefits of using PgBouncer, such as saving resources when reusing database connections, it provides connection pooling for systems that do not have their own connection pool.
Transactions#
YaXAHA Cluster operates transactions, and although modern ORM frameworks automatically wrap each individual database request into a transaction, there are many systems that do not use this isolation mechanism.
To help YaXAHA Cluster, our version of PgBouncer transparently wraps such SQL queries into a transaction. This ensures the isolation of requests from each other and correct work of the cluster.
A small additional component with minimal changes allows YaXAHA Cluster to correctly detect transaction boundaries and work with vanilla PostgreSQL without altering the source code. Also, all PostgreSQL functions are available to the user without any changes.
The patch source code is available at the repository. In fact, it wraps single SQL queries into a transaction and calls the transaction commit function across the entire cluster.
In fact, our patched PgBouncer version wraps every SQL query into a transaction and calls the transaction commit function across the entire cluster.
begin;
…
select yt_complete(true);
commit;PgBouncer Configuration#
Below is an example of a simple PgBouncer configuration. Please refer to Official PgBouncer Documentation for details.
[databases]
* = host=127.0.0.1 port=5432
[pgbouncer]
listen_port = 6432
listen_addr = 127.0.0.1
auth_type = trust
auth_file = userlist.txt
logfile = pgbouncer.log
pidfile = pgbouncer.pid
admin_users = postgres"dbuser" ""