# Topology of tribe nodes in a distributed replicated environment and automatic index + alias creation **URL:** \ **Category:** Elasticsearch\ **Created:** [February 12, 2015, 2:32am UTC](https://discuss.elastic.co/t/topology-of-tribe-nodes-in-a-distributed-replicated-environment-and-automatic-index-alias-creation/22124 "2015-02-12T02:32:08Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![Todd\_Nine](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/todd_nine/32/778_2.png) [@Todd\_Nine](https://discuss.elastic.co/u/Todd_Nine)\ **Post date:** [February 12, 2015, 2:32am UTC](https://discuss.elastic.co/t/topology-of-tribe-nodes-in-a-distributed-replicated-environment-and-automatic-index-alias-creation/22124/1 "2015-02-12T02:32:08Z")
Hey guys, We have a slightly different use case than I'm able to find examples for with the tribe node. Any feedback would be appreciated. What we have now: Single region: We create indexes in our code automatically. They're based on timeuuids, so we never have to worry about them conflicting. We also create read and write aliases to these indexes. We read and write documents to our local region only. What we want: 2+ Region Topology us-west, us-east, asia pac What I'm envisioning. Our Code: We implement a tool that will create a log of all index creations, as well as read and write alias creation. These operations are then replayed individually on each region's cluster. If a region is offline, or unreachable, it won't block other regions getting created. Tribe Nodes: Write to all regions. Is there a way we can do this so that this returns to the caller after our local region has accepted the write? We don't want to wait for all regions to ack the write. Again if a region is offline, we'll lose that ability. We can re-index those documents later. Read: Always read from local cluster for efficiency and responsiveness. We're exploring all options for multi region deployments. Ultimately we'd like reads to occur locally for performance, and are ok with queueing background writes to each region. Thoughts? Thanks, Todd -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/e6dcf03c-b023-4118-ac9b-4cf6701e4885%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/e6dcf03c-b023-4118-ac9b-4cf6701e4885%40googlegroups.com). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![warkolm](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/warkolm/32/39224_2.png) [@warkolm](https://discuss.elastic.co/u/warkolm)\ **Post date:** [February 16, 2015, 8:39am UTC](https://discuss.elastic.co/t/topology-of-tribe-nodes-in-a-distributed-replicated-environment-and-automatic-index-alias-creation/22124/2 "2015-02-16T08:39:58Z")
You need to be careful here because if you are using the same alias for a given in index on all your cluster then the tribe node won't know where it needs to go. But your queuing strategy sounds good. Regarding querying from a local cluster, you can use > **[Elasticsearch Platform — Find real-time answers at scale](https://www.elastic.co)** > > Power insights and outcomes with the Elasticsearch Platform and AI. See into your data and find answers that matter with enterprise solutions designed to help you build, observe, and protect. Try Elasticsearch free today. On 12 February 2015 at 13:32, Todd Nine [tnine@apigee.com](mailto:tnine@apigee.com) wrote: > Hey guys, > We have a slightly different use case than I'm able to find examples for > with the tribe node. Any feedback would be appreciated. > > What we have now: > > Single region: > > We create indexes in our code automatically. They're based on timeuuids, > so we never have to worry about them conflicting. We also create read and > write aliases to these indexes. > We read and write documents to our local region only. > > What we want: > > 2+ Region Topology > > us-west, us-east, asia pac > > What I'm envisioning. > > Our Code: We implement a tool that will create a log of all index > creations, as well as read and write alias creation. These operations are > then replayed individually on each region's cluster. If a region is > offline, or unreachable, it won't block other regions getting created. > > Tribe Nodes: Write to all regions. Is there a way we can do this so that > this returns to the caller after our local region has accepted the write? > We don't want to wait for all regions to ack the write. Again if a region > is offline, we'll lose that ability. We can re-index those documents later. > > Read: Always read from local cluster for efficiency and responsiveness. > > We're exploring all options for multi region deployments. Ultimately we'd > like reads to occur locally for performance, and are ok with queueing > background writes to each region. > > Thoughts? > > Thanks, > Todd > > -- > You received this message because you are subscribed to the Google Groups > "elasticsearch" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). > To view this discussion on the web visit > [https://groups.google.com/d/msgid/elasticsearch/e6dcf03c-b023-4118-ac9b-4cf6701e4885%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/e6dcf03c-b023-4118-ac9b-4cf6701e4885%40googlegroups.com) > [https://groups.google.com/d/msgid/elasticsearch/e6dcf03c-b023-4118-ac9b-4cf6701e4885%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/e6dcf03c-b023-4118-ac9b-4cf6701e4885%40googlegroups.com?utm_medium=email&utm_source=footer) > . > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/CAEYi1X88Ty5dLvBcFfN8x2O9f-RAyBR2iPViD92FNcnfKBWTHQ%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAEYi1X88Ty5dLvBcFfN8x2O9f-RAyBR2iPViD92FNcnfKBWTHQ%40mail.gmail.com). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [July 6, 2017, 12:32am UTC](https://discuss.elastic.co/t/topology-of-tribe-nodes-in-a-distributed-replicated-environment-and-automatic-index-alias-creation/22124/3 "2017-07-06T00:32:33Z")