More info in README please #1

linked opened this Issue Aug 2, 2011 · 1 comment

2 participants


Hey, this really looks great -- like revolutionary, game-changing, ground-breaking-ly great -- but without more info in the README, there's no way for anyone investigating (like me!) to know for sure.

It would be immensely helpful and deeply appreciated if you could include:

  • "Real-world usage!" Is anyone using this in the wild? Have you tested it across datacenters, or just on two local VMs? Neither is less honorable, it's just a matter of being transparent with your end users. If you tell me that you've tested it on two local VMs, I'll test it today in four datacenters worldwide to give you more data.
  • "Scaling is as easy as...." ? How easy is scaling to add a new master? Installing the package looks simple, but what about management and maintenance?
  • Is it "like magic" and "good enough for anyone"?
  • Is migrating from current mysql setups difficult?
  • How long does it take to introduce a new master?
  • Is there a SPOF?
  • What kinds of failover mechanisms are supported? What kinds of load balancing is supported?
  • How is it "multi-master" -- sharded on rows, sharded on tables, not sharded at all?
  • If Master-A holds Key A, and Master-B holds Key B, can you describe performance on a query that returns both A and B (e.g. touches multiple master nodes)?

Thanks so much for opensourcing this magic piece of beauty. This could really change a lot of people's lives and jobs directly. But without more info in the README, it's hard to tell at first glance. Please respond here if there's anything I can do to help you fill this in.



Most of your answers can be found in the documentation:

perldoc MySQL::Replication

If you want to look at it without installing, have a see the raw pod here:

There is also more documentation in the /bin scripts.

I'll ammend the README to point this out.


Q: Is it being used in the real world?
A: Yes. We are using it at Opera Software to replicate multiple masters across data centers

Q: How easy is it to add a new master?
A: Simply run the server on your master, then run a client on the slaves that point to the new master

Q: How about management
A: All configuration is done via command line options. So it's completely scriptable

Q: Is it like magic?
A: No. It's actually quite simple in how it works. Take a look at the documentation for an explaination

Q: Is migration from MySQL's built-in replication difficult?
A: No. The steps are all documented in

Q: Is there a SPOF?
A: Depends on your topology. Since it's all peer-to-peer, you decide if your topology has a SPOF

Q: What kinds of failover mechanisms are supported?
A: There is no failover mechanisms built in. You will have to monitor client progress with the --getstats option and take action as needed

Q: What kinds of load balancing is supported?
A: There is no load balancing built in. Ideally your data will be sharded but there is currently no query filtering support yet.

Q: How is it "multi-master"?
A: Since there is no query filtering support implemented yet, all masters will be full replicas

Q: Can you decribe performance?
A: MySQL::Replication as in MySQL's built-in replication has a minimal impact on replication performance. The biggest factor is the runtime of your queries

Hope this helps. Let me know if it doesn't make any sense and I'll (hopefully) clarify it for you more.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment