This discussion is archived
6 Replies Latest reply: Feb 19, 2013 1:02 PM by Levi-Pereira RSS

2 node RAC vs Master <-> Slave failover

jfbaro Newbie
Currently Being Moderated
Hi there,

I always heard Oracle RAC is a super robust solution when it comes to availability, but how does it (2 node Oracle RAC) compare to MySQL Master-Slave configuration?

They say MySQL Master/Slave can failover in about 5 to 10 seconds, and no data is lost. So the application would drop some connections for 5 to 10 seconds.

What about RAC, is it a zero downtime solution? Would it keep the connections running even if the client was connected to the "faulty" server?

In summary, what makes Oracle RAC (2 nodes) so much better than other solutions (regarding Availability only)?

Cheers
  • 1. Re: 2 node RAC vs Master <-> Slave failover
    P.Forstmann Guru
    Currently Being Moderated
    MySQL Master/Slave is much closer to Data Guard than to RAC.

    Following table describes more the different high availability solutions http://docs.oracle.com/cd/E11882_01/server.112/e17157/unplanned.htm#BABCDHJI.

    Edited by: P. Forstmann on 19 févr. 2013 21:00
  • 2. Re: 2 node RAC vs Master <-> Slave failover
    Nelson Calero Journeyer
    Currently Being Moderated
    Hi,

    These are two different solutions.

    With MySQL replication you get a logical copy of your master database. It allows to have different data at the slave even when replication is running ok. It is your job to take care that this does not happen in your installation.

    MySQL does not have an automatic failover. And you need to use semi-synchronous replication (available since MySQL 5.5) to have all committed transactions on the slave in every possible failure.

    Also, there are many community contributions that brings you more possibilities, like synchronous replication (Galera).

    There are many good references for HA with MySQL, like this paper: http://www.mysql.com/why-mysql/white-papers/mysql-guide-to-high-availability-solutions

    Oracle RAC implements shared access to the only copy of the data. In case of failure, integrity and consistency is given by the database.

    RAC has built in features that allows automatic failover of services running on the database, as well as client connections. This means it is more complex to administer also. You will find a lot of acronyms for different features: Fast Application Notification (FAN), Transparent Application Failover (TAF), Fast Connection Failover (FCF).

    You can read more details about how this works in RAC on this paper: http://www.oracle.com/technetwork/database/features/availability/maa-wp-11gr2-client-failover-173305.pdf

    I hope this helps.

    Regards.
    Nelson
  • 3. Re: 2 node RAC vs Master <-> Slave failover
    Levi-Pereira Guru
    Currently Being Moderated
    jfbaro wrote:
    Hi there,

    I always heard Oracle RAC is a super robust solution when it comes to availability, but how does it (2 node Oracle RAC) compare to MySQL Master-Slave configuration?

    They say MySQL Master/Slave can failover in about 5 to 10 seconds, and no data is lost. So the application would drop some connections for 5 to 10 seconds.

    What about RAC, is it a zero downtime solution? Would it keep the connections running even if the client was connected to the "faulty" server?

    In summary, what makes Oracle RAC (2 nodes) so much better than other solutions (regarding Availability only)?
    I don't like of use term like "no data loss" because this not exists yet.

    You can minimize data loss, because if a data in a transaction that was not commited during a node failure will be lost (I mean RDBSM will rollback all uncomited transaction) and from viewpoint of business there is data loss.


    DBA viewpoint: Zero Downtime on Oracle RAC exists only to SELECT transaction (I mean if you are executing a select and that node fail, the Select will continue on survive nodes whitout reexecute that select). This not happens with UPDATE,INSERT transaction.
    The connection will be automaticaly redirected to survive node, but that transaction will be lost and transaction must be redone. (It may take 1 or 2 second but there is this downtime)


    Zero Downtime means: If a node fails it will be transparent to the end User, if your Oracle RAC is configured properly and your application supports automatic failover (dealing with transactions that have not been commited avoiding data loss).

    Oracle RAC is only a component of HA, so Oracle Provide many productus and tecnology to deploy a HA environment.
    http://www.oracle.com/technetwork/database/availability/index.html


    High Availability Customer Case Studies, Presentations, Profiles, Analyst Reports, and Press Releases
    http://www.oracle.com/technetwork/database/features/ha-casestudies-098033.html
  • 4. Re: 2 node RAC vs Master <-> Slave failover
    P.Forstmann Guru
    Currently Being Moderated
    Nelson Calero wrote:
    RAC has built in features that allows automatic failover of services running on the database, as well as client connections. This means it is more complex to administer also. You will find a lot of acronyms for different features: Fast Application Notification (FAN), Transparent Application Failover (TAF), Fast Connection Failover (FCF).
    FAN and FCF mean also more application development that should not be underestimated.
  • 5. Re: 2 node RAC vs Master <-> Slave failover
    P.Forstmann Guru
    Currently Being Moderated
    Levi Pereira wrote:
    You can minimize data loss, because if a data in a transaction that was not commited during a node failure will be lost (I mean RDBSM will rollback all uncomited transaction) and from viewpoint of business there is data loss.
    I think this notion of data loss will always be an issue with any existing or future DBMS product since DBMS only try to guarantee no loss of committed transactions and never loss of open/pending transactions.
  • 6. Re: 2 node RAC vs Master <-> Slave failover
    Levi-Pereira Guru
    Currently Being Moderated
    P. Forstmann wrote:
    Levi Pereira wrote:
    You can minimize data loss, because if a data in a transaction that was not commited during a node failure will be lost (I mean RDBSM will rollback all uncomited transaction) and from viewpoint of business there is data loss.
    I think this notion of data loss will always be an issue with any existing or future DBMS product since DBMS only try to guarantee no loss of committed transactions and never loss of open/pending transactions.
    I agree.
    They say MySQL Master/Slave can failover in about 5 to 10 seconds, and no data is lost. So the application would drop some connections for 5 to 10 seconds.
    My point is not only about RDBMS, but "no data loss". In this particular case I was careful in say "no data loss". After failover you can't guarantee that all data send to database at time of failure will be there, unless the application can handle with this.

Legend

  • Correct Answers - 10 points
  • Helpful Answers - 5 points