Schema-registry: Schema Registry master election with multiple instances and rest proxies

Created on 11 Jun 2015  路  2Comments  路  Source: confluentinc/schema-registry

Reading through the multi-dc schema registry setup spawned some questions and I couldn't find a better place to ask than here. Let me know if I should repost this elsewhere.

For architecture, I have:

  • 2 Kafka REST Proxy boxes
  • 2 Schema Registry Boxes
  • 3 Zookeeper boxes
  • 3 Kafka brokers
  • Given that I have two Schema Registry (SR) instances, what's the preferred string for schema.registry.url in the Kafka REST Proxy configuration? Does that variable support comma separated strings of SR instances or should I have a round-robin DNS to point at an SR instance randomly?
  • Does having both SR instances with master.eligibility=true cause any problems operationally?
  • Are there preferred practices with SR to allow for redundancy? Does the Single Master architecture handle all of the balancing via Zookeeper? If so, does that indicate that a round-robin dns/load balancer is a necessity when dealing with SR clusters?

Most helpful comment

@cwscribner You can use our community mailing list for questions like this.

  1. https://github.com/confluentinc/schema-registry/pull/184 adds support for multiple SR servers but isn't released yet. For now you'd want to use round-robin DNS or a load balancer.
  2. You can, and should, have multiple instances with master.eligibility=true. This doesn't mean you'll have multiple masters, it's just a flag to control whether that instance _can_ become master. The case where you'll want to turn this off is if you have one data center that has your primary cluster, but you want to replicate the same schema data to another data center. In that case, the instances in the secondary data center should use master.eligibility=false since they are only intended to be mirrors.
  3. The master is responsible for writes, but you can serve reads from any instance. If you're using the currently released version, you can use DNS or a load balancer to balance reads across all the instances. And the instances will forward any writes to the master, so using DNS/load balancer should work fine for everything. With the change linked above, you could list the servers directly in the serializers config. However, you still might want to use the DNS or load balancer approach as it allows you to make changes to the SR cluster without having to reconfigure all your running apps.

All 2 comments

@cwscribner You can use our community mailing list for questions like this.

  1. https://github.com/confluentinc/schema-registry/pull/184 adds support for multiple SR servers but isn't released yet. For now you'd want to use round-robin DNS or a load balancer.
  2. You can, and should, have multiple instances with master.eligibility=true. This doesn't mean you'll have multiple masters, it's just a flag to control whether that instance _can_ become master. The case where you'll want to turn this off is if you have one data center that has your primary cluster, but you want to replicate the same schema data to another data center. In that case, the instances in the secondary data center should use master.eligibility=false since they are only intended to be mirrors.
  3. The master is responsible for writes, but you can serve reads from any instance. If you're using the currently released version, you can use DNS or a load balancer to balance reads across all the instances. And the instances will forward any writes to the master, so using DNS/load balancer should work fine for everything. With the change linked above, you could list the servers directly in the serializers config. However, you still might want to use the DNS or load balancer approach as it allows you to make changes to the SR cluster without having to reconfigure all your running apps.

Perfect, thanks for the response!

Was this page helpful?
0 / 5 - 0 ratings