You can subscribe to this list here.
2010 |
Jan
|
Feb
|
Mar
|
Apr
(10) |
May
(17) |
Jun
(3) |
Jul
|
Aug
|
Sep
(8) |
Oct
(18) |
Nov
(51) |
Dec
(74) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2011 |
Jan
(47) |
Feb
(44) |
Mar
(44) |
Apr
(102) |
May
(35) |
Jun
(25) |
Jul
(56) |
Aug
(69) |
Sep
(32) |
Oct
(37) |
Nov
(31) |
Dec
(16) |
2012 |
Jan
(34) |
Feb
(127) |
Mar
(218) |
Apr
(252) |
May
(80) |
Jun
(137) |
Jul
(205) |
Aug
(159) |
Sep
(35) |
Oct
(50) |
Nov
(82) |
Dec
(52) |
2013 |
Jan
(107) |
Feb
(159) |
Mar
(118) |
Apr
(163) |
May
(151) |
Jun
(89) |
Jul
(106) |
Aug
(177) |
Sep
(49) |
Oct
(63) |
Nov
(46) |
Dec
(7) |
2014 |
Jan
(65) |
Feb
(128) |
Mar
(40) |
Apr
(11) |
May
(4) |
Jun
(8) |
Jul
(16) |
Aug
(11) |
Sep
(4) |
Oct
(1) |
Nov
(5) |
Dec
(16) |
2015 |
Jan
(5) |
Feb
|
Mar
(2) |
Apr
(5) |
May
(4) |
Jun
(12) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(4) |
2019 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
S | M | T | W | T | F | S |
---|---|---|---|---|---|---|
|
|
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
8
|
9
|
10
|
11
|
12
|
13
|
14
|
15
(2) |
16
|
17
(1) |
18
|
19
|
20
|
21
(1) |
22
(1) |
23
(3) |
24
(6) |
25
(3) |
26
(2) |
27
(4) |
28
(6) |
29
(9) |
30
(7) |
31
(20) |
|
From: David E. W. <da...@ju...> - 2014-01-25 23:10:29
|
On Jan 25, 2014, at 2:13 AM, Michael Meskes <me...@po...> wrote: >> Really? You actually have RPMs that depend on Postgres, and add the XC functionality in a binary distribution? > > No. First of all we have DEBs no RPMs. And second of all, what I was meaning to say it we have for instance a Postgres-XC server package, because that is different from PostgreSQL. But we do not have an XC libpq package. Right. libpq should be included in your -libs package or something, right? psql won't work without it. >> But the XC docs include everything from the pg docs, no? > > Yes, afaict. That’s what I thought. Thanks, David |
From: Michael M. <me...@po...> - 2014-01-25 10:13:46
|
On Fri, Jan 24, 2014 at 02:17:13PM -0800, David E. Wheeler wrote: > > We haven't completely solved the coexistance part yet, but mainly due to time > > constraints. What we do so far is only build those pieces of XC that are > > different and rely on the PG packages for the rest. > > Really? You actually have RPMs that depend on Postgres, and add the XC functionality in a binary distribution? No. First of all we have DEBs no RPMs. And second of all, what I was meaning to say it we have for instance a Postgres-XC server package, because that is different from PostgreSQL. But we do not have an XC libpq package. > > I think they have to be part of it. After all people might just install XC > > without PG alongside it. > > But the XC docs include everything from the pg docs, no? Yes, afaict. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at gmail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL |
From: ZhangJulian <jul...@ou...> - 2014-01-25 00:28:20
|
Hi All, I am thinking 3 choices as below: 1. Pacemaker and Corosync. I have little experience on Linux HA, so one week passed, I even can not install them successfully, including Pacemaker/Corosync/crmsh/resouce agent. There are some website mentioned Pacemaker/corosync can help PGXC to build a HA infrastructure, but I can not find a comprehensive guide to do it. There are much more commponents in PGXC than PG, I think I should learn how to build it based on PG first. 2. Zookeeper It seems that Zookeeper has the ability to build a HA solution for PGXC, which have the similar function with Pacemaker, but I have to develop the heartbeat function for Zookeeper to start/stop/monitor/failover PGXC. And I do not know if my understand is right. 3. PGXC support HA internally. Because the table of pgxc_nodes in coordinator already have some information about the cluster, it can be enhanced to save the Master/Slave relations, it is replicated between all coordinators, then it can used as a CRM(Cluster Resource Management, as Pacemaker) compoment. And the coordinator will connect to datanode/gtm/other coordinator in its regular work, so the heartbeat function exists natually. Even when the database is in the spare time, the coordinator can send a simple query as "select 1+1" to datanodes as the heartbeat ticks. What need to do is that, the coordinator will start a new process when starting, the new process will act as a heartbeat /resouce_agent to monitor the cluster status, and restart/failover once one commponent fails. As my initial understanding, Choice 3 is better than Choice 2 which is better than Choice 1. But for the development effort, the order is reversed, Choice 1 is easy achieved based on current existing codes. I am very appreciated that you can share your advice with me. Thanks Julian |