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

Configuration file #3

Open
CSharpDummy opened this issue Nov 9, 2022 · 4 comments
Open

Configuration file #3

CSharpDummy opened this issue Nov 9, 2022 · 4 comments

Comments

@CSharpDummy
Copy link

I'm a bit lost about the configuration file. Can I just define in the docker build process and copy it into the right directory?
Also not sure which directory to store it.

I am trying to use docker compose and set up questdb, the questdb kafka conenctor and redpanda as kafka broker.

@iamkucuk
Copy link

You may want to watch the video in here: https://www.youtube.com/watch?v=Jkcp28ki82k

@jerrinot
Copy link
Collaborator

Hello @CSharpDummy,

indeed it's a bit confusing. In short: Kafka Connect has 2 modes:

  1. Standalone
  2. Distributed

The Standalone mode indeed allows you to define a configuration property file and pass the file as an argument to Kafka Connect. This is described at https://questdb.io/docs/third-party-tools/kafka/questdb-kafka/

However, the Standalone mode has drawbacks in terms of scalability and fault tolerance - there can be only one JVM running the connector - when this crash then you have to restart it.

The Distributed mode has better fault-tolerance properties and also it allows to run the same connect in multiple JVMs. Unfortunately, it's a bit awkward in terms of configuration - you have to start connectors via the REST API.

The video shared by @iamkucuk looks good, I assume it'll explain these concepts into greater details.

I could also add a Dockerized code sample with the standalone mode - given the high performance of QuestDB connector there is not much need for horizontal scalability and failures can be handled on different levels, eg. Kubernetes. So thanks for creating this issue!

@CSharpDummy
Copy link
Author

Ah yes that makes sense. So the connector spans over the cluster.

@jerrinot
Copy link
Collaborator

@CSharpDummy exactly. there is a bit mismatch between the Distributed mode and the way how container orchestrator work. but an individual connector cannot change that.

I'm keeping this issue open as a reminder to add a Standalone code example.

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

No branches or pull requests

3 participants