Menu
▾
▴
postgres-xc-general
|
From: David H. <pg...@c0...> - 2012-10-24 20:59:50
|
Hi, I've been reading the 'ERROR: FAILED TO GET POOLED CONNECTIONS' thread about what XC should and should not do. I opted to start a new thread (instead of replying) about how I would like XC to be. Some background. I work for a SaaS company (mostly dev, some ops) which has to be online 24/7. We are now running apache/tomcat/mysql for each set of customers on about 30 nodes and we want to centralize and make our application more robust, efficient and simple. It basically means creating layers: LB, webservers, application servers, database cluster. Some easy parts are already done (haproxy, nginx). Our 'platform' is pretty complex and I have so many tasks, I prefer to _not_ dig into details. We are now discussing the db issue (mysql cluster is not that great). My dream DB cluster: Scalability - that means read and write scalability. XC should do that right now. Nice. High availability - a node can go offline and it should not hinder availability (only processing capacity) Maintainability - Since maintenance/change is our primary cause of downtime, it should be possible to kill a node and add it later. This can be because the VM is being moved, the OS is updated/upgraded, etc. Also, think about how a cluster is updated from major version to major version (lets say 9.x to 10.x). Maybe that is not an issue (but I don't know about it yet). Simplicity - It would be nice if the default package+config file is all I need. If it is too complex I cannot go on holidays. Some points: * I read that _'...even the stock postgresql.conf configuration file is pretty conservative and users tweak it as per their requirements..._'. For me that translates as 'if you are new to Postgres it works bad'. Not simple (for e.g. some of our dev-ers). * For HA_ '...Like Postgres, you need an external application to provide it'_. When using a cluster I think HA is very often wanted. I need to explain all this to every ops-colleague of mine and some are not very accurate. Not simple again. Quick setup - I want to setup an NxM cluster quickly (N times duplication for HA, M times distributed writes for performance). I prefer to setup a single node with a given config file, add nodes and be ready to go. Maybe an hour in case of disaster recovery? Managability - I want to manage a cluster easily (add node, remove node, spare nodes, monitoring, ...). It cannot be simple enough. Backup - I'm not familiar with running backups on Postgres but we currently run a blocking backup on the mysql, for consistency, and it causes issues. We use Bacula on a file level. Which brings up a question: How do you backup a cluster (if you don't know which nodes are hot)? Logging - Yes... Some may respond that things are not that simple. I know. But I still want it to be simple. It would make PGXC a no-brainer for everyone. Thanks for listening and keep up the good work! I appreciate it. David H. |
|
From: Paulo P. <pj...@ub...> - 2012-10-24 21:40:34
Attachments:
signature.asc
|
Hi, Summing, I've found Postgres-XC to be quite easy to install and configure in a 3 coordinators + 3 data-nodes (GTM all over them and GTM-Proxy handling HA). A little Google and command-line did the trick in *a couple hours*! Now, the only downside for me is that Postgres-XC doesn't have a built-in way of load-balancing between coordinators. If the coordinator your app is pointing to goes down, your app goes down - your application can target all of them, but in my experience, your application will *always* target a host. So, ATM my solution is: 1) Define a DNS FQDN like coordinator.mydomain pointing to an IP (i.e., 10.0.0.1) 2) Point my app to work with that FQDN 3) On every coordinator, configure keepalived with one shared-IP (10.0.0.1) 4) Install haproxy in every coordinator and have it load-balance with the other coordinators This way, keep-alived will always choose the first coordinator (based on its priority) and then haproxy (running on that machine) will load-balance with others. If this coordinator goes down, the second host in keepalived priority list will replace it and not only is it a valid coordinator, but also it will be able to load-balance with other coordinators. My only doubt is, if you get a data-node offline and then bring it up, will the data in that data-node be synchronized? And that's it. I'm in now way a DB-expert and I felt quite confused by reading the previous thread. But as a developer, Postgres-XC has been a huge upgrade for me. (Now, if only RETURN ID was to be implemented, mr. Abbas ;-)). Sorry for being a little off-topic, but wanted to share my _little_ experience with this wonderful piece of software. Cheers, PP On 10/24/12 9:41 PM, David Hofstee wrote: > Hi, > > I've been reading the '*ERROR: Failed to get pooled connections*' thread > about what XC should and should not do. I opted to start a new thread > (instead of replying) about how I would like XC to be. > > Some background. I work for a SaaS company (mostly dev, some ops) which > has to be online 24/7. We are now running apache/tomcat/mysql for each > set of customers on about 30 nodes and we want to centralize and make > our application more robust, efficient and simple. It basically means > creating layers: LB, webservers, application servers, database cluster. > Some easy parts are already done (haproxy, nginx). Our 'platform' is > pretty complex and I have so many tasks, I prefer to /not/ dig into > details. We are now discussing the db issue (mysql cluster is not that > great). > > My dream DB cluster: > > Scalability - that means read and write scalability. XC should do that > right now. Nice. > > High availability - a node can go offline and it should not hinder > availability (only processing capacity) > > Maintainability - Since maintenance/change is our primary cause of > downtime, it should be possible to kill a node and add it later. This > can be because the VM is being moved, the OS is updated/upgraded, etc. > Also, think about how a cluster is updated from major version to major > version (lets say 9.x to 10.x). Maybe that is not an issue (but I don't > know about it yet). > > Simplicity - It would be nice if the default package+config file is all > I need. If it is too complex I cannot go on holidays. Some points: > > * I read that /'...even the stock postgresql.conf configuration file > is pretty conservative and users tweak it as per their > requirements.../'. For me that translates as 'if you are new to > Postgres it works bad'. Not simple (for e.g. some of our dev-ers). > * For HA/'...Like Postgres, you need an external application to > provide it'/. When using a cluster I think HA is very often wanted. > I need to explain all this to every ops-colleague of mine and some > are not very accurate. Not simple again. > > Quick setup - I want to setup an NxM cluster quickly (N times > duplication for HA, M times distributed writes for performance). I > prefer to setup a single node with a given config file, add nodes and be > ready to go. Maybe an hour in case of disaster recovery? > > Managability - I want to manage a cluster easily (add node, remove node, > spare nodes, monitoring, ...). It cannot be simple enough. > > Backup - I'm not familiar with running backups on Postgres but we > currently run a blocking backup on the mysql, for consistency, and it > causes issues. We use Bacula on a file level. Which brings up a > question: How do you backup a cluster (if you don't know which nodes are > hot)? > > Logging - Yes... > > > > Some may respond that things are not that simple. I know. But I still > want it to be simple. It would make PGXC a no-brainer for everyone. > Thanks for listening and keep up the good work! I appreciate it. > > > > David H. > > > > > > > > > > > > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_sfd2d_oct > > > > _______________________________________________ > Postgres-xc-general mailing list > Pos...@li... > https://lists.sourceforge.net/lists/listinfo/postgres-xc-general > -- Paulo Pires Ubiwhere |
|
From: Michael P. <mic...@gm...> - 2012-10-25 00:13:55
|
On Thu, Oct 25, 2012 at 5:41 AM, David Hofstee <pg...@c0...> wrote: > ** > > Hi, > > I've been reading the '*ERROR: Failed to get pooled connections*' thread > about what XC should and should not do. I opted to start a new thread > (instead of replying) about how I would like XC to be. > > Some background. I work for a SaaS company (mostly dev, some ops) which > has to be online 24/7. We are now running apache/tomcat/mysql for each set > of customers on about 30 nodes and we want to centralize and make our > application more robust, efficient and simple. It basically means creating > layers: LB, webservers, application servers, database cluster. Some easy > parts are already done (haproxy, nginx). Our 'platform' is pretty complex > and I have so many tasks, I prefer to *not* dig into details. We are now > discussing the db issue (mysql cluster is not that great). > > My dream DB cluster: > Scalability - that means read and write scalability. XC should do that > right now. Nice. > > High availability - a node can go offline and it should not hinder > availability (only processing capacity) > > Maintainability - Since maintenance/change is our primary cause of > downtime, it should be possible to kill a node and add it later. This can > be because the VM is being moved, the OS is updated/upgraded, etc. Also, > think about how a cluster is updated from major version to major version > (lets say 9.x to 10.x). Maybe that is not an issue (but I don't know about > it yet). > > Simplicity - It would be nice if the default package+config file is all I > need. If it is too complex I cannot go on holidays. Some points: > > - I read that *'...even the stock postgresql.conf configuration file > is pretty conservative and users tweak it as per their requirements...*'. > For me that translates as 'if you are new to Postgres it works bad'. Not > simple (for e.g. some of our dev-ers). > - For HA* '...Like Postgres, you need an external application to > provide it'*. When using a cluster I think HA is very often wanted. I > need to explain all this to every ops-colleague of mine and some are not > very accurate. Not simple again. > > XC is a fork of Postgres and we try to share the same philosophy as the parent project about being really conservative on the things that should or should not be added in core. For example, let's take the case of HA. It is of course possible to implement an HA solution directly in the core of XC, but there are 2 things that would go against that: 1) It is not our goal to oblige the users to user an HA solution or another, and I do not believe that it is the role of core people to integrate directly in XC core a solution that might be good for a certain type of applications, without caring of the other types of applications. Postgres is popular because it lets all the users free to use what they want, and depending on the application people want to use with XC, they might prefer an HA solution or another. 2) If in the future Postgres integrates a native HA solution (I do not believe it will be the case as the community is really conservative, but let's assume), and if XC had a some point integrated an HA solution directly in its core, we would certainly have to drop the XC solution and rely on the Postgres solution as XC is a fork of Postgres. This would be a waste of time for the core people who integrated the HA solution, and people merging Postgres code with XC. One of the reasons explaining that XC is able to keep up with Postgres code pace easily is that we avoid to implement solutions in core that might impact unnecessarily its interactions with Postgres. > > > Quick setup - I want to setup an NxM cluster quickly (N times duplication > for HA, M times distributed writes for performance). I prefer to setup a > single node with a given config file, add nodes and be ready to go. Maybe > an hour in case of disaster recovery? > There are already tools about that like this one written in Ruby: https://sourceforge.net/projects/postgres-xc/files/misc/pgxc_config_v0_9_3.tar.gz/download It is not maintained since 0.9.3 as this is not honestly a part of core. You might have a look at it. > Managability - I want to manage a cluster easily (add node, remove node, > spare nodes, monitoring, ...). It cannot be simple enough. > Sure. I don't know about any utilities able to do that, but if you could build a utility like this running on top of XC and sell it, well you might be able to make some money if XC becomes popular, what is not really the case now ;) > Backup - I'm not familiar with running backups on Postgres but we > currently run a blocking backup on the mysql, for consistency, and it > causes issues. We use Bacula on a file level. Which brings up a question: > How do you backup a cluster (if you don't know which nodes are hot)? > In the case of XC, you might directly take a dump from a Coordinator with pg_dump, and then restore the dump file with pg_restore. You might want to use archive files. There are many ways to accomplish that, like in Postgres. The only difference in the case of XC is that you need to do that for each node as architecture is shared nothing. > Logging - Yes... > > Some may respond that things are not that simple. I know. But I still want > it to be simple. It would make PGXC a no-brainer for everyone. Thanks for > listening and keep up the good work! I appreciate it. > There are already utilities implemented for Postgres that can work natively with XC, like for logging you might want to use log analyzers like pgbadger. You should have a look at that first for each thing you want to do, then evaluate the effort necessary to achieve each of your goals. Thanks, -- Michael Paquier http://michael.otacoo.com |
|
From: Ashutosh B. <ash...@en...> - 2012-10-25 06:32:40
|
On Thu, Oct 25, 2012 at 5:43 AM, Michael Paquier <mic...@gm...>wrote: > On Thu, Oct 25, 2012 at 5:41 AM, David Hofstee <pg...@c0...> wrote: > >> ** >> >> Hi, >> >> I've been reading the '*ERROR: Failed to get pooled connections*' thread >> about what XC should and should not do. I opted to start a new thread >> (instead of replying) about how I would like XC to be. >> >> Some background. I work for a SaaS company (mostly dev, some ops) which >> has to be online 24/7. We are now running apache/tomcat/mysql for each set >> of customers on about 30 nodes and we want to centralize and make our >> application more robust, efficient and simple. It basically means creating >> layers: LB, webservers, application servers, database cluster. Some easy >> parts are already done (haproxy, nginx). Our 'platform' is pretty complex >> and I have so many tasks, I prefer to *not* dig into details. We are now >> discussing the db issue (mysql cluster is not that great). >> >> My dream DB cluster: >> > Scalability - that means read and write scalability. XC should do that >> right now. Nice. >> >> High availability - a node can go offline and it should not hinder >> availability (only processing capacity) >> >> Maintainability - Since maintenance/change is our primary cause of >> downtime, it should be possible to kill a node and add it later. This can >> be because the VM is being moved, the OS is updated/upgraded, etc. Also, >> think about how a cluster is updated from major version to major version >> (lets say 9.x to 10.x). Maybe that is not an issue (but I don't know about >> it yet). >> >> Simplicity - It would be nice if the default package+config file is all I >> need. If it is too complex I cannot go on holidays. Some points: >> >> - I read that *'...even the stock postgresql.conf configuration file >> is pretty conservative and users tweak it as per their requirements... >> *'. For me that translates as 'if you are new to Postgres it works >> bad'. Not simple (for e.g. some of our dev-ers). >> - For HA* '...Like Postgres, you need an external application to >> provide it'*. When using a cluster I think HA is very often wanted. I >> need to explain all this to every ops-colleague of mine and some are not >> very accurate. Not simple again. >> >> XC is a fork of Postgres and we try to share the same philosophy as the > parent project about being really conservative on the things that should or > should not be added in core. > For example, let's take the case of HA. It is of course possible to > implement an HA solution directly in the core of XC, but there are 2 things > that would go against that: > 1) It is not our goal to oblige the users to user an HA solution or > another, and I do not believe that it is the role of core people to > integrate directly in XC core a solution that might be good for a certain > type of applications, without caring of the other types of applications. > Postgres is popular because it lets all the users free to use what they > want, and depending on the application people want to use with XC, they > might prefer an HA solution or another. > 2) If in the future Postgres integrates a native HA solution (I do not > believe it will be the case as the community is really conservative, but > let's assume), and if XC had a some point integrated an HA solution > directly in its core, we would certainly have to drop the XC solution and > rely on the Postgres solution as XC is a fork of Postgres. This would be a > waste of time for the core people who integrated the HA solution, and > people merging Postgres code with XC. One of the reasons explaining that XC > is able to keep up with Postgres code pace easily is that we avoid to > implement solutions in core that might impact unnecessarily its > interactions with Postgres. > +10. I totally agree with Michael here. We would like to keep XC's footprint as small as possible. XC would add features for distributed computing that will not be present in PG. Rest features would come from PG. At the same time, we lack in terms of resources; and hence choose only few things that look to be important from XC's perspective. > >> >> Quick setup - I want to setup an NxM cluster quickly (N times duplication >> for HA, M times distributed writes for performance). I prefer to setup a >> single node with a given config file, add nodes and be ready to go. Maybe >> an hour in case of disaster recovery? >> > There are already tools about that like this one written in Ruby: > > https://sourceforge.net/projects/postgres-xc/files/misc/pgxc_config_v0_9_3.tar.gz/download > It is not maintained since 0.9.3 as this is not honestly a part of core. > You might have a look at it. > >> Managability - I want to manage a cluster easily (add node, remove node, >> spare nodes, monitoring, ...). It cannot be simple enough. >> > Sure. I don't know about any utilities able to do that, but if you could > build a utility like this running on top of XC and sell it, well you might > be able to make some money if XC becomes popular, what is not really the > case now ;) > >> Backup - I'm not familiar with running backups on Postgres but we >> currently run a blocking backup on the mysql, for consistency, and it >> causes issues. We use Bacula on a file level. Which brings up a question: >> How do you backup a cluster (if you don't know which nodes are hot)? >> > In the case of XC, you might directly take a dump from a Coordinator with > pg_dump, and then restore the dump file with pg_restore. You might want to > use archive files. > There are many ways to accomplish that, like in Postgres. The only > difference in the case of XC is that you need to do that for each node as > architecture is shared nothing. > Logging - Yes... >> >> Some may respond that things are not that simple. I know. But I still >> want it to be simple. It would make PGXC a no-brainer for everyone. Thanks >> for listening and keep up the good work! I appreciate it. >> > There are already utilities implemented for Postgres that can work > natively with XC, like for logging you might want to use log analyzers like > pgbadger. > You should have a look at that first for each thing you want to do, then > evaluate the effort necessary to achieve each of your goals. > > Thanks, > -- > Michael Paquier > http://michael.otacoo.com > > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_sfd2d_oct > _______________________________________________ > Postgres-xc-general mailing list > Pos...@li... > https://lists.sourceforge.net/lists/listinfo/postgres-xc-general > > -- Best Wishes, Ashutosh Bapat EntepriseDB Corporation The Enterprise Postgres Company |
|
From: Michael P. <mic...@gm...> - 2012-10-25 00:21:32
|
On Thu, Oct 25, 2012 at 6:40 AM, Paulo Pires <pj...@ub...> wrote: > Hi, > > Summing, I've found Postgres-XC to be quite easy to install and > configure in a 3 coordinators + 3 data-nodes (GTM all over them and > GTM-Proxy handling HA). A little Google and command-line did the trick > in *a couple hours*! > > Now, the only downside for me is that Postgres-XC doesn't have a > built-in way of load-balancing between coordinators. If the coordinator > your app is pointing to goes down, your app goes down - your application > can target all of them, but in my experience, your application will > *always* target a host. So, ATM my solution is: > 1) Define a DNS FQDN like coordinator.mydomain pointing to an IP > (i.e., 10.0.0.1) > 2) Point my app to work with that FQDN > 3) On every coordinator, configure keepalived with one shared-IP > (10.0.0.1) > 4) Install haproxy in every coordinator and have it load-balance with > the other coordinators > > This way, keep-alived will always choose the first coordinator (based on > its priority) and then haproxy (running on that machine) will > load-balance with others. If this coordinator goes down, the second host > in keepalived priority list will replace it and not only is it a valid > coordinator, but also it will be able to load-balance with other > coordinators. > This looks like a possible solution trying to achieve load balancing easily at Coordinator level. You could also publish a small utility for the XC community based in your experience. That is only a suggestion to help community, please understand that I do not force you publishing anything of course. > My only doubt is, if you get a data-node offline and then bring it up, > will the data in that data-node be synchronized? > If the Datanode becomes offline for a certain reason, all the transactions that should have run on it will fail at Coordinator level, so there is no worries here about data synchronization normally. It is btw recommended to have a standby node behing the one that failed if the Datanode that failed cannot be recovered for a reason or another. > And that's it. I'm in now way a DB-expert and I felt quite confused by > reading the previous thread. But as a developer, Postgres-XC has been a > huge upgrade for me. (Now, if only RETURN ID was to be implemented, mr. > Abbas ;-)). > +1. Looking forward to seeing this feature ;-o > Sorry for being a little off-topic, but wanted to share my _little_ > experience with this wonderful piece of software. > Thanks, I am convinced it is helpful for a lot of people -- Michael Paquier http://michael.otacoo.com |
|
From: Vladimir S. <vst...@gm...> - 2012-10-26 11:45:45
|
On Thu, Oct 25, 2012 at 1:40 AM, Paulo Pires <pj...@ub...> wrote: > Summing, I've found Postgres-XC to be quite easy to install and > configure in a 3 coordinators + 3 data-nodes (GTM all over them and > GTM-Proxy handling HA). A little Google and command-line did the trick > in *a couple hours*! In Debian You can install this package in a few seconds. > Now, the only downside for me is that Postgres-XC doesn't have a > built-in way of load-balancing between coordinators. If the coordinator It is not a problem. The problem is necessity to have standby for every data node. > 1) Define a DNS FQDN like coordinator.mydomain pointing to an IP > (i.e., 10.0.0.1) > 2) Point my app to work with that FQDN > 3) On every coordinator, configure keepalived with one shared-IP > (10.0.0.1) > 4) Install haproxy in every coordinator and have it load-balance with > the other coordinators First, haproxy here is extra - keepalived can do all things itself and better. Second, put it on any XC node is bad idea. In any case I prefer full cluster solution with corosync/pacemaker. This way we can put under single cluster control not only database, but all other parts of the system, i.e. web servers and applications servers. But be aware: with this solution we have HA only for LB, but not for datanodes itself. > My only doubt is, if you get a data-node offline and then bring it up, > will the data in that data-node be synchronized? My congratulation. You come at the point about what we are discussing for a long time in neighbor thread. Data from this node if it has no replica on other nodes are not available any more, but Your application don't knows, which data is available and which is not. You can easy imagine consequences. That is moment when down time is started. That is what we have without HA. And that is why You must have standby for every data node. In other word You should build extra infrastructure in size of entire cluster. |
|
From: Nikhil S. <ni...@st...> - 2012-10-26 12:23:04
|
On Fri, Oct 26, 2012 at 5:15 PM, Vladimir Stavrinov <vst...@gm...>wrote: > On Thu, Oct 25, 2012 at 1:40 AM, Paulo Pires <pj...@ub...> wrote: > > > Summing, I've found Postgres-XC to be quite easy to install and > > configure in a 3 coordinators + 3 data-nodes (GTM all over them and > > GTM-Proxy handling HA). A little Google and command-line did the trick > > in *a couple hours*! > > In Debian You can install this package in a few seconds. > > > Now, the only downside for me is that Postgres-XC doesn't have a > > built-in way of load-balancing between coordinators. If the coordinator > > It is not a problem. The problem is necessity to have standby for > every data node. > > Why is that a problem? The standby can run on nodes which are part of your cluster itself. >But be > aware: with this solution we have HA only for LB, but not for > datanodes itself. > > HA for datanodes can be provided by using standy nodes as well. > That is what we have without HA. And that is why You must > have standby for every data node. In other word You should build extra > infrastructure in size of entire cluster. > > It looks like you like the Mysql Cluster product a lot and are trying to force fit PGXC within its parameters. So going back to your favorite Mysql Cluster product. The group has to contain at least two nodes for redundancy, right? Why is that ok and having a replica not ok or not similar? PGXC can/will certainly provide read capabilities from replicas in coming versions. Regards, Nikhils -- StormDB - http://www.stormdb.com The Database Cloud Postgres-XC Support and Service |
|
From: Vladimir S. <vst...@gm...> - 2012-10-26 12:46:53
|
On Thu, Oct 25, 2012 at 4:13 AM, Michael Paquier <mic...@gm...> wrote: > 1) It is not our goal to oblige the users to user an HA solution or another, Sounds fine. Where are those users? Who wants cluster without HA? Everybody when hears word "cluster" implies "HA". > Postgres code with XC. One of the reasons explaining that XC is able to keep > up with Postgres code pace easily is that we avoid to implement solutions in > core that might impact unnecessarily its interactions with Postgres. You are heroes. How long You can continue "code pace" on this hard way? This paradigm prevents You do not implement not only HA but lot of other things that is necessary for cluster. I never saw this type of fork. I believe at some point You will either become a part of Postgres or totally come off and go Your own way. The only question is when? And best answer is "right now". >> Managability - I want to manage a cluster easily (add node, remove node, >> spare nodes, monitoring, ...). It cannot be simple enough. > > Sure. I don't know about any utilities able to do that, but if you could > build a utility like this running on top of XC and sell it, well you might > be able to make some money if XC becomes popular, what is not really the > case now ;) There are no problem with adding or removing nodes. But after that we should something do with data contained in the nodes. In other words, this is data manipulating issue. And it is not about "utility like this running on top of XC". It should be implemented internally. |
|
From: Vladimir S. <vst...@gm...> - 2012-11-05 16:23:02
|
On Tue, Oct 30, 2012 at 10:02 PM, Roger Mayes <rog...@gm...> wrote: > Odd that their list publishes our email addresses, and if I hit "reply" (in > gmail), it goes to the person who made the post rather than to the list. Click arrow on the right of "Reply" button, then click "Reply all". Or copy/past list address into CC: field. > gmail is more-or-less commercial software, isn't it? Lol. No matter commercial or not. More important is open source criteria. > It seems like our conversation has gone a bit afield of the list's topic, > anyway. We continue discussion about HA for XC. > So have you found any way to do get write scalability and high availability? I've already wrote here about this. I think at this time the best solution is alliance of drbd + pacemaker + corosync. It is very effective, reliable and rather simple setup for duplicating every node. I have such architecture running lot of vz boxes. But it is no matter what services are there running. The difference is only resource agent, i.e. start/stop script. BTW among others (most of them are web, application and database servers) there are postgresql running inside those vz boxes without any problems. |
|
From: Vladimir S. <vst...@gm...> - 2012-11-05 16:26:48
|
On Mon, Nov 05, 2012 at 07:22:54PM +0300, Vladimir Stavrinov wrote: > solution is alliance of drbd + pacemaker + corosync. It is very Forgot to add in this team ipvs. ***************************** ### Vladimir Stavrinov ### vst...@gm... ***************************** |
|
From: Koichi S. <koi...@gm...> - 2012-11-06 00:55:59
|
Does anybody has performance data for DRBD with PostgreSQL? The following reports that the throughput will become almost half. http://archives.postgresql.org/pgsql-performance/2007-09/msg00118.php The article is posted about five years ago, though. Regards; ---------- Koichi Suzuki 2012/11/6 Vladimir Stavrinov <vst...@gm...>: > On Mon, Nov 05, 2012 at 07:22:54PM +0300, Vladimir Stavrinov wrote: > >> solution is alliance of drbd + pacemaker + corosync. It is very > > Forgot to add in this team ipvs. > > > ***************************** > ### Vladimir Stavrinov > ### vst...@gm... > ***************************** > > > ------------------------------------------------------------------------------ > LogMeIn Central: Instant, anywhere, Remote PC access and management. > Stay in control, update software, and manage PCs from one command center > Diagnose problems and improve visibility into emerging IT issues > Automate, monitor and manage. Do more in less time with Central > http://p.sf.net/sfu/logmein12331_d2d > _______________________________________________ > Postgres-xc-general mailing list > Pos...@li... > https://lists.sourceforge.net/lists/listinfo/postgres-xc-general |
|
From: David H. <da...@c0...> - 2012-11-07 07:08:43
|
Hi Koichi, Not specifically PostgreSQL, using mysql, and we haven't benchmarked... We run an email marketing company (we basically DDOS ourselves by sending mails fast and receiving clicks back) and have about 20 pizzabox servers in one rack. Each pizzabox has about 5 VMs, most have an active db instance. Using asynchronous DRBD, via a 1Gbps VPLS, we sync to the second location so we have a hot-standby for a server. The average traffic in our usecase is 100Mbps and we peak around 400Mbps during backups (the backupserver is also mirrored of course). I have _never_ seen issues with DRBD is this setting (and we failover regularly for maintenance of the hosts; only the VMs are synced). We used to have synchronous replication when the hosts were coupled together; no issues either. I have to say that our data is not required to be of 'bank quality' (using mysql/myisam will guarantee that). I have seen many more issues from upgrading from Debian Lenny to Debian Squeeze on our Dell R310. I/O performance seems to have lowered significantly, say 20% or 30% (more I/O related incidents since update). These are gut numbers because I have a hard time reproducing this (it only occurs when many users do many different things). We have not located that issue (to any driver, hw and/or kernel changes). However. We basically are not using 50% of our hardware and it hurts my need for optimization. David On 11/06/2012 01:55 AM, Koichi Suzuki wrote: > Does anybody has performance data for DRBD with PostgreSQL? The > following reports that the throughput will become almost half. > > http://archives.postgresql.org/pgsql-performance/2007-09/msg00118.php > > The article is posted about five years ago, though. > > Regards; > ---------- > Koichi Suzuki > > > 2012/11/6 Vladimir Stavrinov <vst...@gm...>: >> On Mon, Nov 05, 2012 at 07:22:54PM +0300, Vladimir Stavrinov wrote: >> >>> solution is alliance of drbd + pacemaker + corosync. It is very >> Forgot to add in this team ipvs. >> >> >> ***************************** >> ### Vladimir Stavrinov >> ### vst...@gm... >> ***************************** >> >> >> ------------------------------------------------------------------------------ >> LogMeIn Central: Instant, anywhere, Remote PC access and management. >> Stay in control, update software, and manage PCs from one command center >> Diagnose problems and improve visibility into emerging IT issues >> Automate, monitor and manage. Do more in less time with Central >> http://p.sf.net/sfu/logmein12331_d2d >> _______________________________________________ >> Postgres-xc-general mailing list >> Pos...@li... >> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general > ------------------------------------------------------------------------------ > LogMeIn Central: Instant, anywhere, Remote PC access and management. > Stay in control, update software, and manage PCs from one command center > Diagnose problems and improve visibility into emerging IT issues > Automate, monitor and manage. Do more in less time with Central > http://p.sf.net/sfu/logmein12331_d2d > _______________________________________________ > Postgres-xc-general mailing list > Pos...@li... > https://lists.sourceforge.net/lists/listinfo/postgres-xc-general -- let op: mijn email is gewijzigd naar da...@c0... |
|
From: Vladimir S. <vst...@gm...> - 2012-11-08 10:28:29
|
On Tue, Nov 6, 2012 at 4:55 AM, Koichi Suzuki <koi...@gm...> wrote: > Does anybody has performance data for DRBD with PostgreSQL? The > following reports that the throughput will become almost half. It is interesting to compare with standby replication solution. |
|
From: Vladimir S. <vst...@gm...> - 2012-11-08 15:11:58
|
On Tue, Nov 6, 2012 at 4:55 AM, Koichi Suzuki <koi...@gm...> wrote: > Does anybody has performance data for DRBD with PostgreSQL? The > following reports that the throughput will become almost half. > > http://archives.postgresql.org/pgsql-performance/2007-09/msg00118.php I've reproduced this test against postgresql-9.1 with similar or even worse results. Though experiment was not clean because of outsider load on system, but kernel and drbd are not most recent. This is confirmed by my other experiment with dd writes where 45% in speed was lost on drbd. But this is one more argument in favor of internal HA where we can expect better results. |
|
From: Koichi S. <koi...@gm...> - 2012-11-08 15:34:23
|
The result looks very similar to the one I've seen. Maybe this is what we should expect with DRBD. ---------- Koichi Suzuki 2012/11/9 Vladimir Stavrinov <vst...@gm...>: > On Tue, Nov 6, 2012 at 4:55 AM, Koichi Suzuki <koi...@gm...> wrote: > >> Does anybody has performance data for DRBD with PostgreSQL? The >> following reports that the throughput will become almost half. >> >> http://archives.postgresql.org/pgsql-performance/2007-09/msg00118.php > > I've reproduced this test against postgresql-9.1 with similar or even > worse results. Though experiment was not clean because of outsider > load on system, but kernel and drbd are not most recent. This is > confirmed by my other experiment with dd writes where 45% in speed was > lost on drbd. But this is one more argument in favor of internal HA > where we can expect better results. |
|
From: Joseph G. <jos...@or...> - 2012-11-08 20:23:55
|
On 9 November 2012 02:34, Koichi Suzuki <koi...@gm...> wrote: > The result looks very similar to the one I've seen. Maybe this is > what we should expect with DRBD. DRBD is very latency sensitive if not using the async modes (which provide less data guarantees). With SSDs and Infiniband (DRBD supports Sockets Direct Protocol over RDMA) you can achieve close to native performance due to very low latency of interconnect. However, application level replication is superior in everyway. > ---------- > Koichi Suzuki > > > 2012/11/9 Vladimir Stavrinov <vst...@gm...>: >> On Tue, Nov 6, 2012 at 4:55 AM, Koichi Suzuki <koi...@gm...> wrote: >> >>> Does anybody has performance data for DRBD with PostgreSQL? The >>> following reports that the throughput will become almost half. >>> >>> http://archives.postgresql.org/pgsql-performance/2007-09/msg00118.php >> >> I've reproduced this test against postgresql-9.1 with similar or even >> worse results. Though experiment was not clean because of outsider >> load on system, but kernel and drbd are not most recent. This is >> confirmed by my other experiment with dd writes where 45% in speed was >> lost on drbd. But this is one more argument in favor of internal HA >> where we can expect better results. > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_nov > _______________________________________________ > Postgres-xc-general mailing list > Pos...@li... > https://lists.sourceforge.net/lists/listinfo/postgres-xc-general -- CTO | Orion Virtualisation Solutions | www.orionvm.com.au Phone: 1300 56 99 52 | Mobile: 0428 754 846 |
|
From: Vladimir S. <vst...@gm...> - 2012-11-13 07:13:11
|
On Fri, Nov 9, 2012 at 12:15 AM, Joseph Glanville <jos...@or...> wrote: > With SSDs and Infiniband (DRBD supports Sockets Direct Protocol over > RDMA) you can achieve close to native performance due to very low If "native performance" means performance of standalone (without DRBD) server, then ... > However, application level replication is superior in everyway. what means "superior" against "close to native performance" above? And what about ceph? I am thinking about it, but never tested yet and have no information about using it with database. -- ********************************** ## Vladimir Stavrinov ## vst...@gm... ********************************** |
|
From: Vladimir S. <vst...@gm...> - 2012-10-26 12:55:56
|
On Thu, Oct 25, 2012 at 4:21 AM, Michael Paquier <mic...@gm...> wrote: > This looks like a possible solution trying to achieve load balancing easily > at Coordinator level. You could also publish a small utility for the XC > community based in your experience. That is only a suggestion to help It is not utility, it is cluster infrastructure and configuration. > It is btw recommended to have a standby node behing the one that failed if > the Datanode that failed cannot be recovered for a reason or another. That's right, this is it. This is result of Your concept: instead of one cluster we should build two clusters. |
|
From: Michael P. <mic...@gm...> - 2012-10-26 13:15:56
|
On Fri, Oct 26, 2012 at 9:55 PM, Vladimir Stavrinov <vst...@gm...>wrote > > That's right, this is it. This is result of Your concept: instead of > one cluster we should build two clusters. > And you have the same notion with PG itself, you create 2 database servers if you use a slave with a master, so I do not see your point, and people live and appreciate such a robust solution.. If you are so of using slaves, you could also use archive files for a recovery, or take periodic dumps of each Datanode if you do not want to lose data, then replay it on a new node if necessary. -- Michael Paquier http://michael.otacoo.com |
|
From: Vladimir S. <vst...@gm...> - 2012-10-26 13:31:48
|
On Fri, Oct 26, 2012 at 10:15:45PM +0900, Michael Paquier wrote: > And you have the same notion with PG itself, you create 2 database The only a small difference: PG is not a cluster. > servers if you use a slave with a master, so I do not see your > point, and people live and appreciate such a robust solution.. If > you are so of using slaves, you could also use archive files for a > recovery, or take periodic dumps of each Datanode if you do not > want to lose data, then replay it on a new node if necessary. All these things needs extra resources while cluster itself should have enough redundancy for fail-over. The difference is that those redundant data in cluster are under work load, i.e. are working, while all other external solutions are dead weight. -- *************************** ## Vladimir Stavrinov ## vst...@gm... *************************** |
|
From: Vladimir S. <vst...@gm...> - 2012-10-26 14:22:15
|
On Fri, Oct 26, 2012 at 05:52:33PM +0530, Nikhil Sontakke wrote: > Why is that a problem? The standby can run on nodes which are part > of your cluster itself. It is already answered many times: because it is extra management, extra recourses and dead weight. > HA for datanodes can be provided by using standy nodes as well. The same as above. > It looks like you like the Mysql Cluster product a lot and are > trying to force fit PGXC within its parameters. So going back to > your favorite Mysql Cluster product. The group has to contain at Again! I have wrote a lot here about mysql. Please, read before write. I don't like mysql, but even enemies may be right. Where this intolerant fanaticism from here where I expect intelligent people? Especially I like "Go away!". You don't want discussion? Then what are You doing here? > least two nodes for redundancy, right? Why is that ok and having a > replica not ok or not similar? PGXC can/will certainly provide read The difference You are pointed out on Yourself in Your next sentences: In an cluster all redundant data are under work load, they are available for read and write, i.e. they are working. But in any external solutions they are sleeping. > capabilities from replicas in coming versions. -- *************************** ## Vladimir Stavrinov ## vst...@gm... *************************** |
|
From: Nikhil S. <ni...@st...> - 2012-10-26 14:34:24
|
> > It looks like you like the Mysql Cluster product a lot and are > > trying to force fit PGXC within its parameters. So going back to > > your favorite Mysql Cluster product. The group has to contain at > > Again! I have wrote a lot here about mysql. Please, read before write. > I don't like mysql, but even enemies may be right. Where this > intolerant fanaticism from here where I expect intelligent people? > Especially I like "Go away!". You don't want discussion? Then what are > You doing here? > > Calm down Vladimir. No one is demonstrating any fanaticism here. I was just pointing out that the group in a Mysql cluster appears similar to a PG server and its replica, just that :) > > least two nodes for redundancy, right? Why is that ok and having a > > replica not ok or not similar? PGXC can/will certainly provide read > > The difference You are pointed out on Yourself in Your next sentences: In > an cluster all redundant data are under work load, they are available for > read and write, i.e. they are working. But in any external solutions > they are sleeping. > > Using a standby is not an external solution. I wrote that PGXC is an ongoing project and will surely use them for reads in the future. Why is that difficult to understand? Anyways, I guess enough on this from my side. Regards, Nikhils -- StormDB - http://www.stormdb.com The Database Cloud Postgres-XC Support and Service |
|
From: Vladimir S. <vst...@gm...> - 2012-10-26 14:59:40
|
On Fri, Oct 26, 2012 at 08:03:54PM +0530, Nikhil Sontakke wrote: > Using a standby is not an external solution. I wrote that PGXC is > an ongoing project and will surely use them for reads It is not the same. What about write? Then You should teach Your application where to read and where to write. What about transparency? No, standby is crutches, it is surrogate. It is not for cluster, it is for standalone database. If You have cluster, You don't need standby. Cluster is best replacement for standby. -- *************************** ## Vladimir Stavrinov ## vst...@gm... *************************** |
|
From: Mason S. <ma...@st...> - 2012-10-26 15:36:56
|
On Fri, Oct 26, 2012 at 10:59 AM, Vladimir Stavrinov <vst...@gm...> wrote: > On Fri, Oct 26, 2012 at 08:03:54PM +0530, Nikhil Sontakke wrote: > >> Using a standby is not an external solution. I wrote that PGXC is >> an ongoing project and will surely use them for reads > > It is not the same. What about write? Then You should teach Your > application where to read and where to write. What about transparency? You can get more write scalability with more data nodes. The project has made a lot of progress since its inception and for a long time a lot of the focus needed to be on just making sure the core database worked. :-) I suspect read balancing for data node standbys will happen at some point. As for HA, I think on this mailing list different ideas were discussed to achieve HA. Koichi Suzuki just did a presentation this week in Prague about HA. Someone else mentioned they are using pgbouncer. We are using Corosync/Pacemaker and have two synchronous replicas per data node. It took years until PostgreSQL itself had built-in replication. Perhaps hooks will be made within XC to help with HA, perhaps there will be an add-on that can be downloaded, perhaps basic data node failover from coordinators could be done (but other components would need failover too). I think most on here also feel strongly about having HA, it is just not built into the core at present. -- Mason Sharp StormDB - http://www.stormdb.com The Database Cloud Postgres-XC Support and Services |
|
From: Vladimir S. <vst...@gm...> - 2012-10-26 16:50:42
|
On Fri, Oct 26, 2012 at 11:36:24AM -0400, Mason Sharp wrote: > > It is not the same. What about write? Then You should teach Your > > application where to read and where to write. What about transparency? > > You can get more write scalability with more data nodes. How it is related with cite above? It is not about scalability, it is about transparency. No matter how much nodes for writes we have. But if You have separate points for read and write, then You loose transparency. > It took years until PostgreSQL itself had built-in replication. I don't blame You don't implement something yet. We have something other point of controversy here. The discussion in these two close threads is about what "must have" and what should not. It is about priority and concept. > I think most on here also feel strongly about having HA, But this discussion shows something else. All my opponents (and I still saw no one supporter ) here very strongly insists, that HA is not high priority for XC or should not be implemented in the core. But my endlessly repeated question "Who wants cluster without HA?" got never answered in any form. So it is become mystery question. > it is just not built into the core at present. "at present" means it will built or possible in the future. Good news. It is first ray of light in the darkness or the light at the end of the tunnel. And it is more important that it come from "Architect and development leader" of XC. Though, it is characteristically, I am not surprised, something like this I expected. Thanks. -- *************************** ## Vladimir Stavrinov ## vst...@gm... *************************** |
Thanks for helping keep SourceForge clean.
X