You can subscribe to this list here.
2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
(6) |
Sep
|
Oct
(19) |
Nov
(1) |
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2011 |
Jan
(12) |
Feb
(1) |
Mar
(4) |
Apr
(4) |
May
(32) |
Jun
(12) |
Jul
(11) |
Aug
(1) |
Sep
(6) |
Oct
(3) |
Nov
|
Dec
(10) |
2012 |
Jan
(11) |
Feb
(1) |
Mar
(3) |
Apr
(25) |
May
(53) |
Jun
(38) |
Jul
(103) |
Aug
(54) |
Sep
(31) |
Oct
(66) |
Nov
(77) |
Dec
(20) |
2013 |
Jan
(91) |
Feb
(86) |
Mar
(103) |
Apr
(107) |
May
(25) |
Jun
(37) |
Jul
(17) |
Aug
(59) |
Sep
(38) |
Oct
(78) |
Nov
(29) |
Dec
(15) |
2014 |
Jan
(23) |
Feb
(82) |
Mar
(118) |
Apr
(101) |
May
(103) |
Jun
(45) |
Jul
(6) |
Aug
(10) |
Sep
|
Oct
(32) |
Nov
|
Dec
(9) |
2015 |
Jan
(3) |
Feb
(5) |
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
(9) |
Aug
(4) |
Sep
(3) |
Oct
|
Nov
|
Dec
|
2016 |
Jan
(3) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(3) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(4) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
S | M | T | W | T | F | S |
---|---|---|---|---|---|---|
|
|
|
|
1
|
2
(3) |
3
|
4
|
5
(5) |
6
(22) |
7
(1) |
8
(4) |
9
|
10
|
11
|
12
|
13
(4) |
14
(6) |
15
(5) |
16
(18) |
17
|
18
|
19
(8) |
20
(1) |
21
|
22
|
23
|
24
|
25
|
26
|
27
|
28
|
29
|
30
|
|
From: Paulo P. <pj...@ub...> - 2012-11-13 12:59:24
|
Hi all, After much reading, I have a couple doubts about recovery. 1) Do we just need to backup Coordinators and Datanodes or GTM as well? 2) Does recovery mean that the cluster should be down? I mean, when recovering, for instance, a datanode or a coordinator, what happens to all the data that has been CRUD'ed into other working nodes? Cheers, -- Paulo Pires |
From: Vladimir S. <vst...@gm...> - 2012-11-13 09:05:30
|
On Tue, Nov 13, 2012 at 06:53:38PM +1100, Joseph Glanville wrote: > Not everything is about performance. Application level replication > will always be superior for other reasons. If You mean replication of standalone database it is other thing. But here we are discussing external HA solution for XC. In this context if chosen, replication should be done for every node separately and its only role is failover. -- ********************************** ## Vladimir Stavrinov ## vst...@gm... ********************************** |
From: Joseph G. <jos...@or...> - 2012-11-13 07:59:30
|
On 13 November 2012 18:13, Vladimir Stavrinov <vst...@gm...> wrote: > 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? Not everything is about performance. Application level replication will always be superior for other reasons. > > And what about ceph? I am thinking about it, but never tested yet and > have no information about using it with database. Ceph RBD or CephFS? CephFS is currently too unstable to be used in production. RBD is stable but it's not optimized for performance, especially not for random IO workloads. > > -- > ********************************** > ## Vladimir Stavrinov > ## vst...@gm... > ********************************** -- 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... ********************************** |