springcloud搭建高可用注册中心的时候注册中心在unavailable-replicas中的问题

  在搭建springcloud eureka高可用注册中心时,发现另一个注册中心一直在unavailable-replicas不可用分片,原因为原来为单个注册中心的时候,禁止了注册中心自主注册为服务和检索服务的功能。使得无法在另一个注册中心注册和检索到另一个服务。

将eureka.client.register-with-eureka=false和eureka.client.fetch-registry=false都改为true

  eureka.client.register-with-eureka意为将自己也作为服务注册,eureka.client.fetch-registry为检索服务。讲这两个开启让两个注册中心相互注册。问题就解决了。

原文地址:https://www.cnblogs.com/lensener/p/8656547.html

时间: 2024-08-03 03:10:34

springcloud搭建高可用注册中心的时候注册中心在unavailable-replicas中的问题的相关文章

Spring Cloud第三篇 | 搭建高可用Eureka注册中心

? ?本文是Spring Cloud专栏的第三篇文章,了解前两篇文章内容有助于更好的理解后面文章: Spring Cloud第一篇 | Spring Cloud前言及其常用组件介绍概览 Spring Cloud第二篇 | 使用并认识Eureka注册中心 ? 一.Eureka注册中心高可用集群概述 1-1.传统架构 在微服务架构的这种分布式系统中,我们要充分考虑各个微服务组件的高可用性问题,不能有单点故障,由于注册中心Eureka本身也是一个服务,如果它只有一个节点,那么它有可能发生故障,这样我们

搭建高可用mongodb集群(四)—— 分片(经典)

转自:http://www.lanceyan.com/tech/arch/mongodb_shard1.html 按照上一节中<搭建高可用mongodb集群(三)-- 深入副本集>搭建后还有两个问题没有解决: 从节点每个上面的数据都是对数据库全量拷贝,从节点压力会不会过大? 数据压力大到机器支撑不了的时候能否做到自动扩展? 在系统早期,数据量还小的时候不会引起太大的问题,但是随着数据量持续增多,后续迟早会出现一台机器硬件瓶颈问题的.而mongodb主打的就是海量数据架构,他不能解决海量数据怎么

搭建高可用mongodb集群—— 分片

从节点每个上面的数据都是对数据库全量拷贝,从节点压力会不会过大? 数据压力大到机器支撑不了的时候能否做到自动扩展? 在系统早期,数据量还小的时候不会引起太大的问题,但是随着数据量持续增多,后续迟早会出现一台机器硬件瓶颈问题的.而mongodb主打的就是海量数据架构,他不能解决海量数据怎么行!不行!“分片”就用这个来解决这个问题. 传统数据库怎么做海量数据读写?其实一句话概括:分而治之.上图看看就清楚了,如下 taobao岳旭强在infoq中提到的 架构图: 上图中有个TDDL,是taobao的一

搭建高可用mongodb集群(四)—— 分片

转载自LANCEYAN.COM 按照上一节中<搭建高可用mongodb集群(三)—— 深入副本集>搭建后还有两个问题没有解决: 从节点每个上面的数据都是对数据库全量拷贝,从节点压力会不会过大? 数据压力大到机器支撑不了的时候能否做到自动扩展? 在系统早期,数据量还小的时候不会引起太大的问题,但是随着数据量持续增多,后续迟早会出现一台机器硬件瓶颈问题的.而mongodb主打的就是海量数据架构,他不能解决海量数据怎么行!不行!“分片”就用这个来解决这个问题. 传统数据库怎么做海量数据读写?其实一句

搭建高可用mongodb集群(三)—— 深入副本集内部机制

http://www.lanceyan.com/tech/mongodb_repset2.html 在上一篇文章<搭建高可用mongodb集群(二)—— 副本集> 介绍了副本集的配置,这篇文章深入研究一下副本集的内部机制.还是带着副本集的问题来看吧! 副本集故障转移,主节点是如何选举的?能否手动干涉下架某一台主节点. 官方说副本集数量最好是奇数,为什么? mongodb副本集是如何同步的?如果同步不及时会出现什么情况?会不会出现不一致性? mongodb的故障转移会不会无故自动发生?什么条件会

搭建高可用MongoDB集群(四):分片

按照上一节中<搭建高可用mongodb集群(三)-- 深入副本集>搭建后还有两个问题没有解决: 从节点每个上面的数据都是对数据库全量拷贝,从节点压力会不会过大? 数据压力大到机器支撑不了的时候能否做到自动扩展? 在系统早期,数据量还小的时候不会引起太大的问题,但是随着数据量持续增多,后续迟早会出现一台机器硬件瓶颈问题的.而mongodb主打的就是海量数据架构,他不能解决海量数据怎么行!不行!"分片"就用这个来解决这个问题. 传统数据库怎么做海量数据读写?其实一句话概括:分而

【转】搭建高可用mongodb集群(四)—— 分片

按照上一节中<搭建高可用mongodb集群(三)—— 深入副本集>搭建后还有两个问题没有解决: 从节点每个上面的数据都是对数据库全量拷贝,从节点压力会不会过大? 数据压力大到机器支撑不了的时候能否做到自动扩展? 在系统早期,数据量还小的时候不会引起太大的问题,但是随着数据量持续增多,后续迟早会出现一台机器硬件瓶颈问题的.而mongodb主打的就是海量数据架构,他不能解决海量数据怎么行!不行!“分片”就用这个来解决这个问题. 传统数据库怎么做海量数据读写?其实一句话概括:分而治之.上图看看就清楚

[转]搭建高可用mongodb集群(四)—— 分片

按照上一节中<搭建高可用mongodb集群(三)—— 深入副本集>搭建后还有两个问题没有解决: 从节点每个上面的数据都是对数据库全量拷贝,从节点压力会不会过大? 数据压力大到机器支撑不了的时候能否做到自动扩展? 在系统早期,数据量还小的时候不会引起太大的问题,但是随着数据量持续增多,后续迟早会出现一台机器硬件瓶颈问题的.而mongodb主打的就是海量数据架构,他不能解决海量数据怎么行!不行!“分片”就用这个来解决这个问题. 传统数据库怎么做海量数据读写?其实一句话概括:分而治之.上图看看就清楚

搭建高可用mongodb shard 集群以及多节点备份

mongodb通过哪些机制实现路由.分片: 从图中可以看到有四个组件:mongos.config server.shard.replica set. mongos,数据库集群请求的入口,所有的请求都通过mongos进行协调,不需要在应用程序添加一个路由选择器,mongos自己就是一个请求分发中心,它负责把对应的数据请求请求转发到对应的shard服务器上.在生产环境通常有多mongos作为请求的入口,防止其中一个挂掉所有的mongodb请求都没有办法操作. config server,顾名思义为配