dpikoto468637
2014-03-16 03:35
浏览 100
已采纳

PHP / PDO MariaDB Galera集群

I am in the final stages of configuring a service that is accessible from four global locations (with plans to add more later). I will be running the servers on an Ubuntu 12.04 box with MariaDB. My initial thought was to create servers that run independently of each other with 4 distinct databases and live with the constraint that users would only be able to login to the server where they were initially registered.

However, I have just run into this article that has got me thinking... .

From my reading of things if I set up a Galera cluster with master-master replication as suggested in the article I can move have the luxury of one large database that is consistently available across all four servers. I have gathered (and am hoping) that with the cluster setup correctly and functioning well I need do pretty much nothing in my PHP code (the four MariaDB instances will have the same user to access the database) - not even alter the PDO connection string.

However, this sounds almost too good to be true. My questions are:

  • are there other issues involved here that make for complications?
  • Do the PHP PDO connection strings need to be altered in anway?
  • Does the fact that my application is already structured to ensure that there is absolutely zero chance of two servers attempting to simultaneously write the same row help?
  • And finally, reading from the MariaDB docs, that this will not work with the TokuDB storage engine?
  • Is there a way to specifically stop the replication of a selected table? Could I in fact exploit the "only InnoDB/XtraDB" constraint and use another storage engine on the table I do not want to have replicated?

图片转代码服务由CSDN问答提供 功能建议

我正处于配置可从四个全球位置访问的服务的最后阶段(计划稍后添加更多内容) )。 我将使用MariaDB在Ubuntu 12.04盒子上运行服务器。 我最初的想法是使用4个不同的数据库创建彼此独立运行的服务器,并遵守用户只能登录到最初注册的服务器的约束。

但是,我刚刚遇到这篇文章让我想到了......

如果我设置了一个带有主人的Galera集群,那么从我的阅读中得知 - 我可以移动的文章中建议的主复制具有一个大型数据库的奢侈,该数据库在所有四个服务器上始终可用。 我已经收集(并且希望)通过集群设置正确且运行良好我需要在我的PHP代码中做很多事情(四个MariaDB实例将拥有相同的用户来访问数据库) - 甚至不改变PDO连接字符串 。

然而,这听起来好得令人难以置信。 我的问题是:

  • 写回答
  • 好问题 提建议
  • 追加酬金
  • 关注问题
  • 收藏
  • 邀请回答

2条回答 默认 最新

  • douzhong1730 2014-03-18 03:07
    已采纳

    are there other issues involved here that make for complications?

    There are some Known Limitations that you should be aware of. Generally, with clusters, you should ideally have an odd number of nodes to prevent split brain conditions, but an even number will usually work just as well.

    Do the PHP PDO connection strings need to be altered in anway?

    No. Your existing connection strings should work.

    Does the fact that my application is already structured to ensure that there is absolutely zero chance of two servers attempting to simultaneously write the same row help?

    Look at the known limitations and make sure your application will still do that. If you're using named locks, you'll need to change your application.

    And finally, reading from the MariaDB docs, that this will not work with the TokuDB storage engine?

    TokuDB support was added in the recent galera cluster distribution. I have used some and it does replicate just like InnoDB but I wouldn't rely on it since it's new in the galera cluster build.

    Is there a way to specifically stop the replication of a selected table? Could I in fact exploit the "only InnoDB/XtraDB" constraint and use another storage engine on the table I do not want to have replicated?

    I've heard a lot of people ask if they can omit tables or databases from replication but I still haven't heard a good reason why. Galera replication provides HA and is cheap and easy so even if some tables aren't important I can't find any realistic reason to not replicate the data. That being said, you could have data not replicated by using MyISAM/Aria.

    I've been using MariaDB with galera in multiple moderately sized projects and it is the best solution I've found for HA and it also provides performance benefits. Other solutions are generally expensive or not mature. One thing you should consider is setting up a proxy for connecting to the database servers like HA Proxy, mysql-proxy, or glbd (which I use) to provide better redundancy and connection balancing for performance.


    In response to DroidOS's comment below:

    1. Every write in the cluster needs to be agreed upon by every node so any latency between nodes is added to every write. So, basically, every write will have the greatest round trip time between the writing server and the other nodes added to it.

    2. No. Galera replication is all or nothing across the entire cluster. If any node has a problem writing the data, which can happen if a table doesn't have a primary key, the node will gracefully kill itself since it can't guarantee its data is consistent with the rest of the cluster. If that happens, the rest of the cluster will continue to operate normally. If there is a network issue, if one of the segments has quorum, it will continue to operate normally. Any segments without quorum will wait for more nodes to get quorum but will not accept queries. With this behavior, you can be sure that any node that you are able to query is consistent with the rest of the cluster.

    评论
    解决 无用
    打赏 举报
查看更多回答(1条)

相关推荐 更多相似问题