>
> What I don't see streaming working for is DR drills. I need to, in a
> controlled manner, move the entire application to the secondary datacenter,
> while keeping all the nodes in sync, make sure everything operates properly
> from there (which means allowing database updates), then move it al
On Mon, 30 Dec 2013 00:15:37 +0800 Sameer Kumar wrote:
> >> > * Quick and easy movement of the master to any of the database in
> >> >
> >> > the cluster without destroying replication.
> >> >
> >> > Again, which version? Re-mastering is made simple in v9.3.
>
> >> I'm not seeing that in the d
>> > * Quick and easy movement of the master to any of the database in
>> >
>> > the cluster without destroying replication.
>> >
>> > Again, which version? Re-mastering is made simple in v9.3.
>> I'm not seeing that in the documentation. In fact, what I'm finding
>> seems to suggest the opposi
On Tue, 24 Dec 2013 14:39:42 +0800 Sameer Kumar wrote:
>
> * Cascading replication chains (a really big deal when you want
>
> multiple slaves in the secondary facility and don't want to hog
>
> your bandwidth)
>
> Really? which version of Postgres are we talking about? I think cascaded
> r
Though I will agree that slony is a nice and a great tool w.r.t.
replication (specifically selective replication). But I would dis-agree on
below points:
* Cascading replication chains (a really big deal when you want
multiple slaves in the secondary facility and don't want to hog
your band
> It looks like it's been morphed into TED, the TransLattice Elastic
> Database. From their FAQ[1]:
>
> TransLattice Elastic Database (TED)
>
> What’s the basis of TED? Did you write it from scratch?
>
> We started TED from PostgreSQL, a very robust, open-source,
> ACID-compliant, fully transac
On Sun, Dec 15, 2013 at 9:40 AM, Wolfgang Keller wrote:
>
> > > Instead it lists Postgres-R, which has been in koma for how long
> > > now... Can't even remember any more.
> >
> > Nope, it is actively developed and sponsored by Translattice.
>
> "Actively developed"?
>
> http://www.postgres-r.org/
> > Instead it lists Postgres-R, which has been in koma for how long
> > now... Can't even remember any more.
>
> Nope, it is actively developed and sponsored by Translattice.
"Actively developed"?
http://www.postgres-r.org/ lists the last entry in the column "News" on
the right with a date of 2
On 12/12/2013 08:18 AM, Wolfgang Keller wrote:
2. Synchronous multi-master configuration
Now back to the original thread:
Knowing the number of forks/projects based on Postgres, maintaining a
list on a wiki list the one below is just easier for everybody:
http://wiki.postgresql.org/wiki/R
I should have cross-posted this to pgsql-docs from the beginning, sorry
for the mistake.
For pgsql-docs readers:
The issue is that the official documentation misleadingly omits the
existence of Postgresql-XC:
http://www.postgresql.org/docs/9.3/static/different-replication-solutions.html?
> Syn
Postgres-XC isn't PostgreSQL. Entirely different product.
>
> Anyone can add pages to the wiki, and there's lots of information
> there about things that aren't postgresql, Postgres-XC is just
> one of those.
>
I think "entirely different product" is not really accurate. It isn't just
a fork, but
On Thu, Dec 12, 2013 at 3:19 AM, Wolfgang Keller wrote:
>> >> postgresql-xc is not postgresql, its a fork.
>>
>> > It would at least merit being mentioned in the doc, just like other
>> > "forks" or whatever you may call it, as long as they're open-source.
>>
>> You seem to not realize how many fo
To be honest your request/demand expectation is quite unfair.
have you seen cross link on Suse and Red Hat and Ubuntu and SE Linux and
Debian and... (well I would need a google search for adding more here)
By far I guess PostgreSQL community documentation is the one of the most
organized doc store
> >> postgresql-xc is not postgresql, its a fork.
>
> > It would at least merit being mentioned in the doc, just like other
> > "forks" or whatever you may call it, as long as they're open-source.
>
> You seem to not realize how many forks of Postgres there are.
I had mentioned just one.
And th
Tom Lane wrote:
> Wolfgang Keller writes:
>>> postgresql-xc is not postgresql, its a fork.
>
>> It would at least merit being mentioned in the doc, just like
>> other "forks" or whatever you may call it, as long as they're
>> open-source.
>
> You seem to not realize how many forks of Postgres th
Wolfgang Keller writes:
>> postgresql-xc is not postgresql, its a fork.
> It would at least merit being mentioned in the doc, just like other
> "forks" or whatever you may call it, as long as they're open-source.
You seem to not realize how many forks of Postgres there are.
There's no way that w
> > Seems to me that the editing process of the different parts of
> > postgresql.org somewhat lacks transactional semantics.
>
> postgresql-xc is not postgresql, its a fork.
As an end-user, why would I care.
Since, besides that it's still open-source (even same license as
PostgreSQL itself...?)
On 12/10/2013 8:47 AM, Wolfgang Keller wrote:
Seems to me that the editing process of the different parts of
postgresql.org somewhat lacks transactional semantics.
postgresql-xc is not postgresql, its a fork.there's other forks that
offer distributed databases, such as greenplum.
--
jo
On Dec 10, 2013, at 8:47 AM, Wolfgang Keller wrote:
>> http://www.postgresql.org/docs/9.3/static/different-replication-solutions.html?
>
>> Synchronous Multimaster Replication
>
> *snip*
>
>> PostgreSQL does not offer this type of replication (...)
>
> Now I compare that statement with:
>
>
> http://www.postgresql.org/docs/9.3/static/different-replication-solutions.html?
> Synchronous Multimaster Replication
*snip*
> PostgreSQL does not offer this type of replication (...)
Now I compare that statement with:
http://wiki.postgresql.org/wiki/Postgres-XC
> Project Overview
*snip*
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> Columns 1-3 and 5 could say "Entire Cluster". Column 4 might say
> "Selected tables (Slony)", and I'm not sure off-hand what granularity #6
> (Bucardo) is capable of. Column #7 might just say "Varies".
Bucardo and Slony are both table-bas
On Mon, 09 Dec 2013 11:09:21 -0500 Thomas Harold
wrote:
> On 11/22/2013 5:57 AM, Albe Laurenz wrote:
> > Kaushal Shriyan wrote:
> >> I have read on the web that Postgresql DB supports replication
> >> across data centers. Any real life usecase examples if it has been
> >> implemented by anyone.
On 12/9/2013 11:24 AM, Ben Chobot wrote:
Out of curiosity what did you find unclear about
http://www.postgresql.org/docs/9.3/static/different-replication-solutions.html?
Perhaps the "Per-table granularity" line in the matrix (Table 25-1)
might be better written as:
"Synchronization Granular
Thomas Harold wrote:
> On 11/22/2013 5:57 AM, Albe Laurenz wrote:
>> Kaushal Shriyan wrote:
>>> I have read on the web that Postgresql DB supports replication
>>> across data centers. Any real life usecase examples if it has been
>>> implemented by anyone.
>>
>> Well, we replicate a 1 TB database
On Dec 9, 2013, at 8:09 AM, Thomas Harold wrote:
> On 11/22/2013 5:57 AM, Albe Laurenz wrote:
>> Kaushal Shriyan wrote:
>>> I have read on the web that Postgresql DB supports replication
>>> across data centers. Any real life usecase examples if it has been
>>> implemented by anyone.
>>
>> Well,
On 11/22/2013 5:57 AM, Albe Laurenz wrote:
Kaushal Shriyan wrote:
I have read on the web that Postgresql DB supports replication
across data centers. Any real life usecase examples if it has been
implemented by anyone.
Well, we replicate a 1 TB database between two locations. It is a
fairly ac
On Fri, Nov 22, 2013 at 11:46 PM, Albe Laurenz wrote:
> Michael Paquier wrote:
>> On Fri, Nov 22, 2013 at 10:03 PM, Kaushal Shriyan
>> wrote:
>>> I am not sure i understand the difference between async and sync replication
>>> and on what scenarios i should use async or sync replication. Does it
Michael Paquier wrote:
> On Fri, Nov 22, 2013 at 10:03 PM, Kaushal Shriyan
> wrote:
>> I am not sure i understand the difference between async and sync replication
>> and on what scenarios i should use async or sync replication. Does it mean
>> if it is within same DC then sync replication is the
On Fri, Nov 22, 2013 at 9:44 PM, Albe Laurenz wrote:
> Torsten Förtsch wrote:
>>> Don't use synchronous replication if you have a high transaction
>>> rate and a noticable network latency between the sites.
>>>
>>> Wait for the next bugfix release, since a nasty bug has just
>>> been discovered.
>
On Fri, Nov 22, 2013 at 10:03 PM, Kaushal Shriyan
wrote:
> I am not sure i understand the difference between async and sync replication
> and on what scenarios i should use async or sync replication. Does it mean
> if it is within same DC then sync replication is the best and if it is
> across DC
On Fri, Nov 22, 2013 at 6:14 PM, Albe Laurenz wrote:
> Torsten Förtsch wrote:
> >> Don't use synchronous replication if you have a high transaction
> >> rate and a noticable network latency between the sites.
> >>
> >> Wait for the next bugfix release, since a nasty bug has just
> >> been discover
Torsten Förtsch wrote:
>> Don't use synchronous replication if you have a high transaction
>> rate and a noticable network latency between the sites.
>>
>> Wait for the next bugfix release, since a nasty bug has just
>> been discovered.
>
> Can you please explain or provide a pointer for more info
On 22/11/13 11:57, Albe Laurenz wrote:
> Don't use synchronous replication if you have a high transaction
> rate and a noticable network latency between the sites.
>
> Wait for the next bugfix release, since a nasty bug has just
> been discovered.
Can you please explain or provide a pointer for m
Em 22/11/2013 08:43, Kaushal Shriyan escreveu:
Hi,
I have read on the web that Postgresql DB supports replication across
data centers. Any real life usecase examples if it has been
implemented by anyone. Please also help me understand the caveats i
need to take care if i implement this setup.
Kaushal Shriyan wrote:
> I have read on the web that Postgresql DB supports replication across data
> centers. Any real life
> usecase examples if it has been implemented by anyone.
Well, we replicate a 1 TB database between two locations.
It is a fairly active OLTP application, but certainly not
35 matches
Mail list logo
