Skip to content
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

fix(clustered): Closes https://github.com/influxdata/DAR/issues/472. … #5885

Open
wants to merge 1 commit into
base: jts/dar-484-add-steps-to-install-kubit-in-an-air-gapped-environment
Choose a base branch
from

Conversation

jstirnaman
Copy link
Contributor

…Catalog terminology is confusing, needs scaling recommendations:

  • Distinguish between Catalog store (Postgres db) and Catalog service (API and cache for the store).
  • Add scaling recommendations for each.
  • Resolve conflicting scaling info, remove duplicated scaling info from storage-engine.md.

Not completed:

  • dashboard (catalog-cache) and monitoring information: I don't currently have access or know-how to test this myself.

…fusing, needs scaling recommendations:

- Distinguish between Catalog store (Postgres db) and Catalog service (API and cache for the store).
- Add scaling recommendations for each.
- Resolve conflicting scaling info, remove duplicated scaling info from storage-engine.md.
Copy link
Collaborator

@sanderson sanderson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good. Just to sum up, we're now distinguishing between the Catalog store and the Catalog service. @reidkaufmann, do you feel this is sufficient?

Copy link
Contributor

@reidkaufmann reidkaufmann left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't see the suggested changes to router, ingester, or querier scaling that I included in the DAR. Did you want me to file a new DAR with those?

The Catalog store is a PostgreSQL-compatible database that persistently stores metadata.
Scaling strategies depend on your chosen PostgreSQL implementation.
All support [vertical scaling](#vertical-scaling), and most support
[horizontal scaling](#horizontal-scaling) for redundancy and failover.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Might be worth noting that "an underprovisioned catalog store can result in write outages." @marcdavoli I think it would be good to give a concrete example of what we do in Cloud Dedicated. Can you suggest something here.

object storage services used to run the object store.
Most support [horizontal scaling](/influxdb3/clustered/admin/scale-cluster/#horizontal-scaling)
for redundancy, failover, and increased capacity.

### Compactor

The Compactor processes and compresses partitions in the [Object store](#object-store)
to continually optimize storage.
It then updates the [Catalog](#catalog) with locations of compacted data.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably should say there should be one pod and to utilize vertical scaling.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants