| title | Multi-node configuration | |||
|---|---|---|---|---|
| excerpt | Sunsetted v2.14.x. Configure the main settings in your multi-node TimescaleDB instance | |||
| keywords |
|
|||
| seo |
|
import MultiNodeDeprecation from "versionContent/_partials/_multi-node-deprecation.mdx";
In addition to the regular $TIMESCALE_DB configuration, it is recommended that you also configure additional settings specific to multi-node operation.
Each of these settings can be configured in the postgresql.conf file on the
individual node. The postgresql.conf file is usually in the data directory,
but you can locate the correct path by connecting to the node with psql and
giving this command:
SHOW config_file;After you have modified the postgresql.conf file, reload the configuration to
see your changes:
pg_ctl reloadIf not already set, ensure that max_prepared_transactions is a non-zero value
on all data nodes is set to 150 as a starting point.
On the access node, set the enable_partitionwise_aggregate parameter to on.
This ensures that queries are pushed down to the data nodes, and improves query
performance.
On the access node, set jit to off. Currently, JIT does not work well with
distributed queries. However, you can enable JIT on the data nodes successfully.
On the data nodes, disable statement_timeout. If you need to enable this,
enable and configure it on the access node only. This setting is disabled by
default in $PG, but can be useful if your specific environment is suited.
On the data nodes, set the wal_level to logical or higher to
move or copy chunks between data nodes. If you
are moving many chunks in parallel, consider increasing max_wal_senders and
max_replication_slots as well.
For consistency, if the transaction isolation level is set to READ COMMITTED
it is automatically upgraded to REPEATABLE READ whenever a distributed
operation occurs. If the isolation level is SERIALIZABLE, it is not changed.