<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Transactional consistency - snapmirror sync / semi sync in ONTAP Discussions</title>
    <link>https://community.netapp.com/t5/ONTAP-Discussions/Transactional-consistency-snapmirror-sync-semi-sync/m-p/7043#M1504</link>
    <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;So how can you protect databases real time if they will always be crash consistent? Scripts or SM products are executed at scheduled times so seconds &amp;nbsp;after this time the data has exceeded the RPOs?&lt;/P&gt;&lt;P&gt;Also, does sync and semi sync also transfer snapshots like &amp;nbsp;async?&lt;/P&gt;&lt;P&gt;Thanks&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
    <pubDate>Wed, 12 Oct 2011 19:31:23 GMT</pubDate>
    <dc:creator>nsitps1976</dc:creator>
    <dc:date>2011-10-12T19:31:23Z</dc:date>
    <item>
      <title>Transactional consistency - snapmirror sync / semi sync</title>
      <link>https://community.netapp.com/t5/ONTAP-Discussions/Transactional-consistency-snapmirror-sync-semi-sync/m-p/7031#M1500</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Is it fair to say that SME / SMSQL etc would not be needed with snapmirror if using snapmirror sync or semi-sync as replicas are not async point-in-time snaps. With sync or semi sync writes to disk are affectively captured on the destination disk... ????&amp;nbsp; &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;This is assuming SME etc is only being used to provide consistent replicas and is not used as a backup product...&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Thu, 05 Jun 2025 06:43:49 GMT</pubDate>
      <guid>https://community.netapp.com/t5/ONTAP-Discussions/Transactional-consistency-snapmirror-sync-semi-sync/m-p/7031#M1500</guid>
      <dc:creator>nsitps1976</dc:creator>
      <dc:date>2025-06-05T06:43:49Z</dc:date>
    </item>
    <item>
      <title>Transactional consistency - snapmirror sync / semi sync</title>
      <link>https://community.netapp.com/t5/ONTAP-Discussions/Transactional-consistency-snapmirror-sync-semi-sync/m-p/7035#M1502</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Hi,&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;I would say this assumption is a bit risky - it follows the logic of other storage vendors who say preserving write order is good enough to be able to recover from a remote replica.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;To me it means that in the event of an actual sudden outage mirrored volumes are crash-consistent, as (presumably) none of the application at the primary site has been put in a hot-backup mode prior to outage. Depending on your luck you may, or may not be able to restore services. If you are unlucky &amp;amp; things go pear-shaped, there are no application-consistent recovery points.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;For that reason I think SnapManager products (or scripted equivalents) are still useful, regardless of replication mode.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Regards,&lt;BR /&gt;Radek&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Wed, 12 Oct 2011 16:51:56 GMT</pubDate>
      <guid>https://community.netapp.com/t5/ONTAP-Discussions/Transactional-consistency-snapmirror-sync-semi-sync/m-p/7035#M1502</guid>
      <dc:creator>radek_kubka</dc:creator>
      <dc:date>2011-10-12T16:51:56Z</dc:date>
    </item>
    <item>
      <title>Transactional consistency - snapmirror sync / semi sync</title>
      <link>https://community.netapp.com/t5/ONTAP-Discussions/Transactional-consistency-snapmirror-sync-semi-sync/m-p/7043#M1504</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;So how can you protect databases real time if they will always be crash consistent? Scripts or SM products are executed at scheduled times so seconds &amp;nbsp;after this time the data has exceeded the RPOs?&lt;/P&gt;&lt;P&gt;Also, does sync and semi sync also transfer snapshots like &amp;nbsp;async?&lt;/P&gt;&lt;P&gt;Thanks&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Wed, 12 Oct 2011 19:31:23 GMT</pubDate>
      <guid>https://community.netapp.com/t5/ONTAP-Discussions/Transactional-consistency-snapmirror-sync-semi-sync/m-p/7043#M1504</guid>
      <dc:creator>nsitps1976</dc:creator>
      <dc:date>2011-10-12T19:31:23Z</dc:date>
    </item>
    <item>
      <title>Transactional consistency - snapmirror sync / semi sync</title>
      <link>https://community.netapp.com/t5/ONTAP-Discussions/Transactional-consistency-snapmirror-sync-semi-sync/m-p/7046#M1505</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Well, it is a very good question.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;I often argue that Continuous Data Protection (CDP) for databases is a bit of a fiction, as you need some checkpoints / markers which represent consistent state of a database.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;You may get zero RPO with synchronous replication if you are lucky - if you are unlucky, you need to roll back to the latest checkpoint.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;It also varies between different database technologies, e.g. Oracle should come back no matter what (there is a TR describing 'dirty' NetApp snapshots as valid Oracle backups).&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;For MS SQL synchronous replication of logs with async replication for databases is probably as close as you can get to a near-zero RPO solution (another TR describes this in detail).&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Regards,&lt;/P&gt;&lt;P&gt;Radek&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Wed, 12 Oct 2011 20:44:56 GMT</pubDate>
      <guid>https://community.netapp.com/t5/ONTAP-Discussions/Transactional-consistency-snapmirror-sync-semi-sync/m-p/7046#M1505</guid>
      <dc:creator>radek_kubka</dc:creator>
      <dc:date>2011-10-12T20:44:56Z</dc:date>
    </item>
    <item>
      <title>Transactional consistency - snapmirror sync / semi sync</title>
      <link>https://community.netapp.com/t5/ONTAP-Discussions/Transactional-consistency-snapmirror-sync-semi-sync/m-p/7055#M1508</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Looking for an RPO of 30 / 60 seconds for SQL - What would you do? RTO is not as tight as RPO so this is not an issue and we have this covered. Do you have the TR# re SQL Sync as I can't seem to find it... &lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Thu, 13 Oct 2011 08:08:04 GMT</pubDate>
      <guid>https://community.netapp.com/t5/ONTAP-Discussions/Transactional-consistency-snapmirror-sync-semi-sync/m-p/7055#M1508</guid>
      <dc:creator>nsitps1976</dc:creator>
      <dc:date>2011-10-13T08:08:04Z</dc:date>
    </item>
    <item>
      <title>Transactional consistency - snapmirror sync / semi sync</title>
      <link>https://community.netapp.com/t5/ONTAP-Discussions/Transactional-consistency-snapmirror-sync-semi-sync/m-p/7060#M1510</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;This is the TR:&lt;/P&gt;&lt;P&gt;&lt;A class="jive-link-external-small" href="http://www.netapp.com/us/library/technical-reports/tr-3604.html" target="_blank"&gt;http://www.netapp.com/us/library/technical-reports/tr-3604.html&lt;/A&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;It actually proved me wrong &lt;SPAN __jive_emoticon_name="wink" __jive_macro_name="emoticon" class="jive_macro jive_emote" src="https://community.netapp.com/4.5.5/images/emoticons/wink.gif"&gt;&lt;/SPAN&gt;, as the solution utilising sync SnapMirror does not involve SMSQL.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;It does not ignore potential problems with consistency though &amp;amp; proposes a workaround in Appendix B:&lt;/P&gt;&lt;P&gt;&lt;EM&gt;&lt;SPAN&gt;In case of problems attaching the database at the DR site caused by checkpointing activity, please follow the procedures below. More about checkpoints may be found at the following link: &lt;/SPAN&gt;&lt;A class="jive-link-external-small" href="http://msdn2.microsoft.com/en-us/library/ms189573.aspx" target="_blank"&gt;http://msdn2.microsoft.com/en-us/library/ms189573.aspx&lt;/A&gt;&lt;SPAN&gt;.&lt;/SPAN&gt;&lt;/EM&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;And the final comment:&lt;/P&gt;&lt;P&gt;&lt;EM&gt;The above-mentioned workaround may result in data loss subject to the recovery.&lt;/EM&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Regards,&lt;/P&gt;&lt;P&gt;Radek&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Thu, 13 Oct 2011 10:59:55 GMT</pubDate>
      <guid>https://community.netapp.com/t5/ONTAP-Discussions/Transactional-consistency-snapmirror-sync-semi-sync/m-p/7060#M1510</guid>
      <dc:creator>radek_kubka</dc:creator>
      <dc:date>2011-10-13T10:59:55Z</dc:date>
    </item>
    <item>
      <title>Transactional consistency - snapmirror sync / semi sync</title>
      <link>https://community.netapp.com/t5/ONTAP-Discussions/Transactional-consistency-snapmirror-sync-semi-sync/m-p/7064#M1512</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Great, I will take a look over this.&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Thu, 13 Oct 2011 12:47:08 GMT</pubDate>
      <guid>https://community.netapp.com/t5/ONTAP-Discussions/Transactional-consistency-snapmirror-sync-semi-sync/m-p/7064#M1512</guid>
      <dc:creator>nsitps1976</dc:creator>
      <dc:date>2011-10-13T12:47:08Z</dc:date>
    </item>
  </channel>
</rss>

