Making the impossible: 3 nodes intercontinental replication--转载

原文:http://www.percona.com/blog/2012/01/11/making-the-impossible-3-nodes-intercontinental-replication/

In this post I want to show new possibilities which open with Percona XtraDB Cluster.
We will create 3 nodes Cluster with nodes on different continents (Europe, USA, Japan) and each node will accept write queries.
Well, you theoretically could create 3 node traditional MySQL ring replication, but this is not what you want to use day-to-day.

To show how it works I will use Amazon m1.xlarge instances, by one in Tokyo, Ireland and North California, running RedHat Entreprise 6.2 64bit.

In fact to create instances is most time consuming task. After that using my script you will have cluster running in 5 min or less.

There however some precautions needed if you run Amazon instances.
First, you need to open ports in the firewall. For the communication the nodes need, by default, 4444, 4567, 4568 ports
(see our FAQ why)

Second, please take into account that the communication is done using open channels, and you may want to establish an encrypted connection, using it in real life.

Now, as we have running instances, you can install Cluster packages from RPM repositories.
You can follow steps from documentation.

Or I prepared simple script which does all the work: http://percona.com/downloads/Percona-XtraDB-Cluster/scripts/intercont.tar.gz,
you also can follow steps from the script to adjust it for your environment.

You just need to change nodes host names and your keys in the file: install.nodes.sh

When all nodes start, we have running 3 nodes EU<->USA<->JAPAN, and each node is ready to execute both read and write queries.

Of course you may wonder what is query response time in such environment. We can check it.

Simple table: CREATE TABLE t (ID INT) and simple query: INSERT INTO t VALUES (1)

Response time on single node in EU (no cluster setup): 0.005100 sec
Response time on two-nodes (EU<->JAP) cluster: 0.275642 sec
Response time on three-nodes (EU<->JAP<->USA) cluster: 0.294754 sec

Well, one may argue that 0.27 sec for single query is kind of big, but this is the physic law, you cannot
go faster than speed of light, and the round trip between Europe and Japan takes time (or at least until scientists figure out how to attach transaction to Faster than light neutrino).
Also note, that XtraDB Cluster can apply events in parallel and throughput should be less affected by big distance.

时间: 2024-08-04 15:06:43

Making the impossible: 3 nodes intercontinental replication--转载的相关文章

action support分析

Action这一部分主要是数据(索引)的操作和部分集群信息操作. 所有的请求通过client转发到对应的action上然后再由对应的TransportAction来执行相关请求.如果请求能在本机上执行则在本机上执行,否则使用Transport进行转发到对应的节点.action support部分是对action的抽象,所有的具体action都继承了support action中的某个类.这里将对这些抽象类进行分析. 这一部分总共分为broadcast(广播),master,nodes,repli

Client requested master to start replication from impossible position; the last event was read from

一:问题描述 由于10.0.3.96此虚拟机所在的物理机存储不够了,所以上面的数据库也无法访问了.后来10.0.3.96可以正常访问后,其从库10.0.3.97却发生了异常: mysql> show slave status \G;    *************************** 1. row ***************************                   Slave_IO_State:                       Master_Host

【转载】MySQL Replication 环境安装与配置

安装[[email protected] ~]# yum install mysql-serverInstalled:mysql-server.x86_64 0:5.1.73-3.el6_5 Dependency Installed:mysql.x86_64 0:5.1.73-3.el6_5perl-DBD-MySQL.x86_64 0:4.013-3.el6perl-DBI.x86_64 0:1.609-4.el6 启动并修改密码[[email protected] ~]# service m

Got fatal error 1236 from master when reading data from binary log: &#39;Client requested master to start replication from impossible position&#39;

[[email protected] bin]# mysqlbinlog logbin.000002 /*!40019 SET @@session.max_insert_delayed_threads=0*/; /*!50003 SET @[email protected]@COMPLETION_TYPE,COMPLETION_TYPE=0*/; DELIMITER /*!*/; # at 4 #150511 20:57:36 server id 1 end_log_pos 106 Start:

redis学习六 集群的原理(转载)

转载自 http://shift-alt-ctrl.iteye.com/blog/2285470 一.Redis Cluster主要特性和设计     集群目标 1)高性能和线性扩展,最大可以支撑到1000个节点:Cluster架构中无Proxy层,Master与slave之间使用异步replication,且不存在操作的merge.(即操作不能跨多个nodes,不存在merge层) 2)一定程度上保证writes的安全性,需要客户端容忍一定程度的数据丢失:集群将会尽可能(best-effort

redis源码分析(8)——replication

redis的主从同步用于实现高可用,并且可以实现读写分离,用于抗大量读请求.通过两种方式指定一个slave从master复制: - 在配置文件中配置:slaveof <masterip> <masterport> - 或者在客户端中执行命令:slaveof <master> <masterport> 这两种方式对应的操作很简单,都是将server.repl_state设置为REDIS_REPL_CONNECT,即将slave设置成同步的初始状态,并设置ser

[转载]系统运维秘诀大分享专题

系统运维秘诀大分享专题 本专题整合收录了有关系统运维/系统管理员工作和个人成长方面的各种心得分享.经验总结.以及必须牢记的一些准则,适合所有在运维领域有追求的技术人阅读.有些分享的层次比较深,有些则是运维的基础课,但通过翻看他人的心得,相信你总能有所收获. 1 Dormando的系统运维秘诀三部曲... 4 1.1 技术篇... 4 1.1.1 为变化而设计.... 4 1.1.2 使用自动的,可重复的构建过程.... 4 1.1.3 使用冗余.... 4 1.1.4 使用备份.... 5 1.

[转载]HDFS初探之旅

转载自 http://www.cnblogs.com/xia520pi/archive/2012/05/28/2520813.html , 感谢虾皮工作室这一系列精彩的文章. Hadoop集群(第8期)_HDFS初探之旅 1.HDFS简介 HDFS(Hadoop Distributed File System)是Hadoop项目的核心子项目,是分布式计算中数据存储管理的基础,是基于流数据模式访问和处理超大文件的需求而开发的,可以运行于廉价的商用服务器上.它所具有的高容错.高可靠性.高可扩展性.高

运行时候报异常could only be replicated to 0 nodes instead of minReplication (=1). There are 2 datanode(s) running and no node(s) are excluded in this operation.

运行时候报异常could only be replicated to 0 nodes instead of minReplication (=1).  There are 2 datanode(s) running and no node(s) are excluded in this operation. 解决方法: 1首先看一下dfs.replication的数目是否超过了datanode的数目,应该要小于或者等于datanode的数目. 2更改mapreduce.map.memory.mb