Re: Real application clustering in postgres.
| От | Andrew Kerber |
|---|---|
| Тема | Re: Real application clustering in postgres. |
| Дата | |
| Msg-id | CAJvnOJYUpF4qwKb7nvKd1KutPuMH6kqvZ9qVqWiQr2mB9iQphg@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Real application clustering in postgres. (Ron <ronljohnsonjr@gmail.com>) |
| Ответы |
Re: Real application clustering in postgres.
|
| Список | pgsql-general |
Yup, if you need true shared storage, Oracle RAC is still the only solution out there, All the other multi-master solutions work by capturing the sql statements themselves. And properly configured it RAC is indeed part of an HA solution. Any time you have everything in a single data center, as you do with basic RAC, you do have a potential single point of failure however, a tornado for example can take out the entire data center. There are solutions like stretch RAC that can account for that issue, as well as data guard. Oracle also has a nice DR feature called Dataguard, which creates an exact duplicate of your running database..The nice point of oracle dataguard is that it is a block by block copy, while all of the Postgres Multi-Master and master-slave replication solutions work by SQL capture.
Potentially DRDB could be used to set up a standby database for postgres, though it is considerably more involved to create than Oracle data guard.
With the advent of virtualization and the concomitant ease of adding CPU and memory to a running database instance, the use cases for true Oracle RAC are much less than in the past, scalability is no longer nearly the issue it used to be, and with the speed of failover at the virtual guest level, the HA requirements are much less substantial than in the past. There are probably still some use cases where the down time required for patching is not acceptable, in which case RAC is still required. The same is true for Postgres or any other Multi-Master instances of course, unless the intent of clustering/multi-master is availability instead of scalability, there isnt much point considering the ease of adding resources to virtual servers.
On Fri, Mar 6, 2020 at 10:56 AM Ron <ronljohnsonjr@gmail.com> wrote:
On 3/6/20 8:55 AM, Laurenz Albe wrote:
> On Fri, 2020-03-06 at 03:25 -0600, Ron wrote:
>>> RAC is not really a high availability solution: because of the shared
>>> storage, it has a sibgle point of failure.
>> This is utter nonsense. Dual redundant storage controllers
>> connected to disks in RAID-10 configurations have been around for at
>> least 25 years.
>>
>> Oracle got it's clustering technology from DEC, and I know
>> that works. Cluster members, storage controllers and disks have all
>> gone down, while the database and application keep on humming along.
> I am not saying that it is buggy, it is limited by design.
>
> If you have mirrored disks, and you write junk (e.g, because of
> a flaw in a fibre channel cable, something I have witnessed),
> then you have two perfectly fine copies of the junk.
Why do you have just one FC path?
> I am not saying the (physical) disk is the single point of failure, the
> (logical) file system is (Oracle calls it ASM / tablespace, but it is
> still a file system).
Why isn't the filesystem (or RDBMS) throwing checksum errors? This was
standard stuff in legacy Enterprise RDBMSs 20 years ago.
--
Angular momentum makes the world go 'round.
--
Andrew W. Kerber
'If at first you dont succeed, dont take up skydiving.'
'If at first you dont succeed, dont take up skydiving.'
В списке pgsql-general по дате отправления:
Следующее
От: Andres FreundДата:
Сообщение: Re: Is it safe to rename an index through pg_class update?