cassandra多数据中心的配置

cassandra默认建keyspace的时候，是需要制定拓扑策略的，小数据就直接用单数据中心的simpleStrategy了,网上资料都没具体提如何配置多数据中心，这里简单贴一下

cassandra.yaml里面修改endpoint_snitch

具体的snitch方式有

simpleSnitch

默认的，单数据中心

GossipingPropertyFileSnitch

官方推荐在生产环境下使用，本节点的rack和dc名字保存在cassandra-rackdc.properties，并且会通过gossip这个p2p协议传播到所有节点上去
如果cassandra-topology.properties文件存在，cassandra会把两个properties文件的结果合并，如果两个properties文件里面有有同一个节点的配置，以cassandra-rackdc.properties的配置为准。

PropertyFileSnitch

dc和rack通过显式的定义在cassandra-topology.properties文件里面

建keyspace的时候，这样指定

CREATE KEYSPACE "test_keyspace" WITH REPLICATION = {‘class‘ : ‘NetworkTopologyStrategy‘, ‘dc1‘ : 3, ‘dc2‘ : 2};

意思是采用网络多数据中心策略，有两个数据中心，dc1的replica factor为3，dc2的replica factor为2

参考的地址http://www.datastax.com/documentation/cql/3.1/cql/cql_reference/create_keyspace_r.html

时间： 2024-08-25 06:15:57

cassandra多数据中心的配置的相关文章

多数据中心的高可用结构【环状星型数据库架构】

贴一些比较老的内容,文章是新写的,技术可能都是大家熟悉的,给入门的兄弟们参考.高手轻拍原文请见:http://www.muduo.net/index.php/u ... space-itemid-318728 二.多数据中心的高可用结构[环状星型数据库架构]在介绍该结构之前,我们首先了解一下mysql复制的有关内容.在<highperformance mysql>的第一版中,作者介绍了这样的一种数据库结构:                              三个mysql的daemon

开源 | 携程Redis多数据中心解决方案-XPipe

Redis在携程内部得到了广泛的使用,根据客户端数据统计,整个携程全部Redis的读写请求在200W QPS/s,其中写请求约10W QPS/S,很多业务甚至会将Redis当成内存数据库使用. 这样,就对Redis多数据中心提出了很大的需求,一是为了提升可用性,解决数据中心DR(DisasterRecovery)问题:二是提升访问性能,每个数据中心可以读取当前数据中心的数据,无需跨机房读数据.在这样的需求下,XPipe应运而生 . 从实现的角度来说,XPipe主要需要解决三个方面的问题,一是数据

易趣：使用MongoDB创建关键业务的多数据中心应用

eBay:使用MongoDB创建关键业务的多数据中心应用 作为全球前十的零售品牌,eBay的活跃用户有一亿七千多万,并拥有跨越全世界190个市场的10亿购物清单,这样的规模下,eBay绝对不允许出现宕机的情况.这也就是为什么公司会依赖于MongoDB提供企业级平台标准以及面向用户的应用. 在今年的MongoDB World conference大会上,eBay的首席NoSQL DBA,Feng Qu,为大家展示了他以及他的团队开发的用来支持企业级MongoDB部署的一整套架构-弹性应用的实用设计

SpringCloudConfig与SpringCloudEureka 注册中心与配置中心高可用的意义

所有的配置会缓存在本地,远程配置中心DOWN机,不影响本地使用,只是无法重新请求服务端获取配置的更新. 不管是注册中心的高可用,还是配置中心的高可用.本质上都是保证服务能注册上去或者能从配置中心获取配置. 注册中心的高可用,意味着如果有一台注册中心DOWN机,其他的注册中心同样能提供注册和查询服务,即使所有注册中心服务器全面down机,其实也不影响提供者和消费者的使用,因为当服务消费者第一次去请求注册中心之后,会把提供者的地址缓存在本地,同样可以直接调用提供者提供的服务(服务提供者可以部署多台机

spring cloud 注册中心 instance_id 配置

spring cloud 注册中心 instance_id 配置 consul 注册发现中心 instance_id 配置 ip + 端口 一般网上推荐的配置都是 ${spring.application.name}:${vcap.application.instance_id:${spring.application.instance_id:${random.value}}} ${random.value} 每次再重启后都会生成一个随机数 会造成每次重启后会在 consul 上重新注册注册上一

Cassandra 集群核心配置和概梳理

Cassandra是一款分布式的结构化数据存储方案(NoSql数据库),存储结构比Key-Value数据库(像Redis)更丰富,但是比Document数据库(如Mongodb)支持度有限:适合做数据分析或数据仓库这类需要迅速查找且数据量大的应用.Cassandra 集群特性比较丰富,考虑场景也比较多,如果想用好集群,集群本很多概念都要能够了解,下面对相关概念进行简介: 与关系数据库相关概念: keyspace -> table –> column,对应关系型数据库 database ->

工作中心后台配置及维护

PRO->工厂维护和客户服务->维护工厂.工作中心.人物列表和PRTS 1.基本设置 2.计划维护 3.工作中心 A.一般数据(在建立工作中心时,需要输入输入工作中心类别,就需要到一般数据中配置) 一般数据->定义工作中心类型并连接到任务列表应用(TCODE:OIZA) B.任务列表数据 C.给工作中心配置平模顺序 4.任务列表 5.生产资源/工具 6.服务合同

Spring Cloud(Dalston.SR5)--Config 集群配置中心-刷新配置

远程 SVN 服务器上面的配置修改后,需要通知客户端来改变配置,需要增加 spring-boot-starter-actuator 依赖并将 management.security.enabled 设置为 false,然后访问客户端的 /refresh 端点进行刷新,访问改端点要使用 HTTP 的 POST 方法,客户端的 refresh 在接收到请求后,会重新到配置服务器获取最新的配置,然后用新的配置和旧配置进行对比,最终把有修改的配置 Key 返回给调用者. 在实际应用中,往往不仅是刷新一个

分布式配置中心config-client配置报错：java.lang.IllegalStateException: duplicate key: spring

今天练习分布式配置中心,写config-client配置文件,使用bootstrap.properties配置,运行没有问题. bootstrap.properties: spring.application.name=config-client spring.cloud.config.label=master spring.cloud.config.profile=dev spring.cloud.config.uri= http://localhost:8888/ server.port=8