-
Notifications
You must be signed in to change notification settings - Fork 87
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
First draft on TSDB 2.3 and PG 11 deprecation. #71
Conversation
Link to build for this PR: http://docs-dev.timescale.com/docs-timescaledb-2.3-release-notes |
- Compression policies on distributed hypertables | ||
- Partially mutable compressed chunks to support INSERTs into a compressed hypertable. | ||
- Downgrading between Timescale DB 2.x versions. | ||
- High Availability: Adding nodes to a multinode cluster. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe that the next version is focusing on elasticity and specifically rebalancing load when adding new DNs, not high availability?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Draft PR, so WIP. But yes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Acceptance Criteria
A data node can be added to the multi-node cluster
Data is written to the new data node after it is added
Old data/chunks are moved from existing nodes to the new nodes to free up space and immediately make use of the new capacity
(Optional) All the steps can be automated
Tasks
Ability to add a data node to a multi-node cluster
Ability to move chunks to the new data node to make use of it immediately. This need not mean a "balanced" cluster.
A way to find candidate chunks to move. For example, based on number of chunks on a node (move from the node with the most chunks), least disk space, and/or based on recent/old chunks.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While this functionality is useful for HA, and is part of the larger HA story, it is a bit misleading to label it High Availability for this release. I agree with @mfreed that we should label this "Elasticity".
Timescale is working hard on our next exciting features. | ||
To make that possible, we require functionality that is unfortunately absent on | ||
PostgreSQL 11. | ||
For this reason, Timescale DB 2.3 will be the last version supporting PostgreSQL 11. | ||
From TimescaleDB 2.4 forward we will no longer support PostgreSQL 11. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Timescale is working hard on our next exciting features. | |
To make that possible, we require functionality that is unfortunately absent on | |
PostgreSQL 11. | |
For this reason, Timescale DB 2.3 will be the last version supporting PostgreSQL 11. | |
From TimescaleDB 2.4 forward we will no longer support PostgreSQL 11. | |
Timescale is working hard on our next exciting features. To make that | |
possible, we require functionality that is unfortunately absent on | |
PostgreSQL 11. For this reason, TimescaleDB 2.3 will be the final | |
version that supports PostgreSQL 11. TimescaleDB 2.4 will require | |
PostgreSQL 12 or 13. |
Co-authored-by: Mike Freedman <mike@timescale.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Had one nit, but approving.
Co-authored-by: Erik Nordström <819732+erimatnor@users.noreply.github.com>
Fixes: #70