Re: Cluster/redundancy question

Поиск
Список
Период
Сортировка
От Alex Stapleton
Тема Re: Cluster/redundancy question
Дата
Msg-id 317959A6-D895-47F5-B26F-ABB59D23F523@advfn.com
обсуждение исходный текст
Ответ на Re: Cluster/redundancy question  (Scott Marlowe <smarlowe@g2switchworks.com>)
Список pgsql-general
Don't forget that MySQL replication also has a habit of silently
failing on you and in my experience needs continuous monitoring to
make sure it actually keeps reasonably up to date (e.g. not days of
data behind on the slaves.)

That was a while ago though, maybe they fixed it?
British Telecom use Slony as well, so I guess it can't be *that* bad?

On 11 Oct 2005, at 17:38, Scott Marlowe wrote:

> On Mon, 2005-10-10 at 15:16, Travis Brady wrote:
>
>> All,
>>
>> Forgive me if this has been answered before, but I've searched the
>> archives and the net extensively and have come up mostly empty so
>> far.
>>
>> I'm working at convincing my firm to implement a postgresql database
>> cluster.
>> Specifically, we'd like to get a few machines running to be more
>> available and to protect against any kind of failure.
>>
>> Right now people are leaning toward MySQL and Emic, but I've been
>> evangelizing for postgres for the standard reasons.
>> How does one go about setting this kind of thing up?
>> I've looked at Bizgres and Pervasive but I'm not sure if that's
>> necessarily what we want.
>>
>
> If you're looking at the replication systems FIRST, then you've
> missed a
> few steps.  Look at what the databases, sans replication, can bring to
> the table, and what they lack.
>
> If you MUST have a database that checks input against check
> constraints,
> then MySQL is out.  It simply doesn't support them.
>
> If you need a database that converts the number 234987234987234987234
> into 2147483647 when you insert it into an int field and doesn't throw
> an error or warning, then MySQL should be your choice.
>
> How important is good transactional performance?  MySQL has serious
> limitations for certain storage engines and you need to compare those
> things before looking at replication.
>
> Don't get me wrong, if replication is one of the things you need, then
> consider it, but if you're putting bad data into your database, what
> good is replicating it gonna do ya?
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster
>


В списке pgsql-general по дате отправления:

Предыдущее
От: Bricklen Anderson
Дата:
Сообщение: Re: fine tuned database dump/reload?
Следующее
От: "Rafael Montoya"
Дата:
Сообщение: Re: exceptions