数据库系统处在信息系统的核心位置，是系统正常运行的必要基础。因此，在选择一款数据库时，数据库的性能和稳定性是我们首要考虑的方面。毕竟谁也不想把自己的大楼建在摇摆的地基上，这样可能永远无法摆脱后续维稳加固工作带来的困扰。如果所选择的产品因为自身技术能力的局限性，永远达不到用户的要求，最终只能重新选型数据库，这对用户来说虽算不上致命，但也大伤元气。
       在数年的工作中，我们参与解决过很多起因人为或者硬件故障导致的数据库故障，而这些问题也都因为前期的系统架构设计不完善导致系统停运时间过长。那本文就从这些问题出发，结合达梦数据库成熟的产品，用最简单的方式介绍达梦数据库是如何为应用系统助力的。

场景一 “阵列硬盘坏了，数据库读写文件异常，系统停运啦！”

       近年来，遇到太多的类似问题。系统建设初期，用户最先考虑的都是磁盘阵列自身的RAID机制。“坏了几块硬盘无所谓，我们可以通过阵列的冗余热插拔更换硬盘”，听了太多的这种胸有成竹。但是，面对永远无法预知的硬件故障，我们无法想象到它会坏到什么程度。我们遇到过的最糟糕的一个案例是存储在某次重启后挂载不上了，只能进行重新格式化。整体格式化！这不是开玩笑，对，就是所有的数据就在那一瞬间都化作一股青烟，烟消云散~
       为了保证最起码的数据安全，在系统建设之初，需要优先考虑数据的冗余。这样就需要两份独立的数据存储空间，一份存储空间出现极端灾难后，另一份可以快速接管访问请求，继续对外提供服务。
       首先，大家不要被HA集群误导，在选择HA集群时一定要清楚他能做什么。单纯的操作系统层级的HA集群实现的是对服务器的冗余，而对存储上的数据依然是单点。他更多的是来进行VIP地址、磁盘阵列、数据库服务的管理。当主机服务器出现异常后，整体可以挂载到冷备备机。对，没错，就是把磁盘阵列挂载到冷备备机，原封不动的挂载。所以，他对数据库来说就是个单机。当然，现在市面上的一些数据库本身带了HA功能（在主备集群中提供VIP地址挂载的功能），大家区别他与操作系统HA的区别就是看他有几份数据。如果只有一份，那就要小心了，可能他的HA就是实现了操作系统的HA功能，进行VIP和存储的挂载管理。在出现存储故障时，他也无法提供持续的访问功能。
       在针对这种场景时，我们可以选择采用达梦的数据守护集群[1]或者读写分离集群[2]。应用的写入入口永远是主机，主机将REDO日志包通过达梦MAL邮件系统发送到备机进行日志重做，实现高效的数据同步功能。备机对外支持只读事务，在读写分离集群下可以实现对应用透明的只读事务自动分发到备库，主备之间数据同步可以选择高性能模式和强一致模式。并且，集群支持一主多备以及异步备机。在此不做过多解释，详见官方文档[^1]。
       在主机存储出现故障后，通过确认监视器的仲裁，备机可以快速切换为主机。应用程序在支持自动重连的情况下，不需要做任何改动即可连接到新主机。对新主机的数据修改都会记录在数据库的归档日志中，当原故障主机恢复后，会以备机模式加入集群，新主机做的数据变动可同步到备机。在DM8版本中，确认监视器也支持了多副本部署，避免了确认监视器的单点故障。

场景二 “不小心执行了TRUNCATE操作，核心业务表被清空，系统关键功能无法使用！”

       这是DBA最无语的技术请求了，面对如此霸气而胸有成竹的操作，你都无力反驳。乖乖的去找最近的数据库的备份是否成功，再根据操作时间点，采用物理备份加归档的方式还原到TRUNCATE操作之前。整库数据量在100GB以内，恭喜你，在一切操作流畅的情况下，十多分钟应该能够完成恢复。如果你的数据总量达到TB级，那就站在旁边擦汗吧（可不能删库跑路~）。有人会说，闪回啊，一闪不就回去了吗？达梦目前针对TRUNCATE操作无法闪回。ORACLE可以闪回TRUNCATE，但是对于在线系统操作的复杂性和风险性大家可以评估下，况且在线系统的UNDO_RETENTION配置的有限大。
       为了避免类似问题的发生，通过严格的在线系统数据库的管控可以一定程度上避免。但是，总是存在一些边开发边上线的系统。那针对这种情况，达梦通过扩展异步备机功能，实现数据的快速恢复。对于达梦数据守护或者DMHS数据同步软件都可以搭建异步备机功能，比如我们设置每天3点同步一次。那就可以从异步备库取出删除前的数据，但是今天白天数据表可能做了很多变动，我怎么把这部分数据也能拿出来。这个我们就可以通过增加一个手动进行数据同步的功能，把数据追加到误删除之前的时刻，然后从异步备库取出数据即可。这个增量数据的追加，对于一般的业务系统来说都是很快的。

       而对于数据量大的系统，如果没有足够的备库存储空间，可以选择使用DMHS[3]实现可配置化的局部数据库对象异步同步，配置为定时同步模式，当需要将备库同步到误删除之前的状态时，通过控制台执行手动同步命令完成从上次同步开始的差额数据同步。

详细方案见：

场景三 “在硬件投入变化不大的情况下，现有系统如何实现双活”

       双活是系统建设的高级目标，系统建设要达到双活的效果需要从应用层和数据库层进行综合设计。对于数据库层，可以依赖自身的相关解决方案实现数据库双活，降低用户数据库层双活设计的工作量。
       实现系统双活后有哪些优势呢，我们来列举一些：
 充分利用软硬件资源，避免了主备模式下只有在备库切主后才会充分使用服务器和磁盘阵列资源的缺点；
 提升系统的吞吐量，双活节点支持同时读写；
 故障无缝切换
 等等……
       借助于达梦数据库的共享存储集群DM DSC[4]，替换了原主备架构模式。在DM DSC集群下，多个数据库实例节点可以同时读写一份共享数据。同时，多个节点对等访问共享存储数据，可以利用多台机器的资源承载更高的数据库并发访问。当集群中一个节点出现故障后，健康节点可以继续对外提供服务，提高系统可用性。为了提升数据的可靠性，可以配合达梦的数据守护集群或读写分离集群搭建实时备机。采用国产数据库即可完成原O数据库的高级方案替代！

       对于更高要求的两地三中心方案，除了采用数据守护集群或者DMHS实时同步软件实现一主多备的集群架构模式外，还可以采用跨机房的DSC集群部署方式，实现两机房的完全双活。跨机房部署DM DSC集群，难点在于如何实现共享存储。现阶段需要依赖于存储提供的存储双活功能，实现将两个机房的两套磁盘阵列虚拟为一套共享存储，供上层数据库搭建DM DSC集群使用。当然，达梦也在研发基于DM ASM镜像功能，后续会推出完全依赖自身产品的跨机房DM DSC解决方案。

总结

       上述选取了几个在项目中经常遇到的场景向大家介绍了达梦数据库在应对数据库容灾时能够为用户带来的解决方案。数据库作为业务系统的底层支撑，需要我们在设计之初就要选择符合业务需求的部署架构，避免在遇到极端人为或者物理灾难时才发现数据库架构设计是系统中最薄弱的环节。达梦作为国产数据库的优秀企业，始终坚持完全自研，为用户提供全栈的数据解决方案。

[1] 详细介绍见 https://eco.dameng.com/docs/zh-cn/start/dm-cluster.html
[2] 详细介绍见https://eco.dameng.com/docs/zh-cn/start/dm-cluster.html
[3] 详细介绍见https://eco.dameng.com/docs/zh-cn/start/dmhs-product-introduction.html
[4] 详细介绍见https://eco.dameng.com/docs/zh-cn/start/dm-asm-cluster.html