Salesforce数据库故障丢失5小时数据,仅仅是个案?

简介:

先来看看Salesforce是个什么公司,云计算企业中的大佬,中国区的网页是这样介绍的:

 

 

您的所有销售、服务和营销数据尽在指尖,但是有将近5小时的数据蒸发了,不好意思哈!

 

Salesforce从1999年到现在,目前Salesforce的数据中心在美国东西海岸,日本,新加坡,都柏林。Salesforce 连续多年在IDC GATNER的评比上成为最具创新企业的第一名。据Celnet雨花石(Salesforce中国区合作伙伴)创始人裘思博(Fledman)介绍,“多租户架构是Salesforce的基础。Cloud database用的是Oracle的数据库以及相关技术。在往上分为3个部分,force.com 平台、heroku、wave。”

 

整个云数据库用的是Oracle,这个Oracle云数据库是怎么丢的数据呢?

 

我们来看看国外媒体对salesforce的报道。Eweek.com 5月11日的文章说:

A Salesforce.com database is back up butnot at full capacity. The more than day-long issue left customers frustratedand 5 hours of data permanently lost.

 

面对众多客户的大量抱怨,CEO Benioff在twitter上道歉:

I am sorry for our service disruption onNA14; please email me ceo@salesforce.com so we can call you. 

Salesforce丢失近5个小时客户数据之后并没有更明确的赔偿或补偿,只是留了一个邮箱而已。

 

据说这次Salesforce发生客户数据丢失主要因数据中心停电造成,在一个大型数据中心的一次大停电之后,Salesforce客户有近5个小时的数据再也找不回来了:

"We have determined that data writtento the NA14 instance between 9:53 UTC and 14:53 UTC on May 10, 2016 could notbe restored."

 

对于2015年全财年收入53.7亿美元、日事务过13亿的Salesforce来说,数据丢失的影响无疑是巨大的,客户的数据啊。

 

据了解,造成数据丢失的原因是,宕机后工作人员希望将数据库恢复到5小时以前的状态,但不幸的是,这一操作导致了故障的发生,进而导致了数据丢失。但是,Salesforce.com的用户们没有签署SLA,这也就意味着这样的故障发生,salesforce将不会给予赔偿。当然,这个不是要讨论的重点。

 

对于使用Oracle数据库的云服务提供商来说,居然没有容灾,而是考虑用备份来恢复,而且还失败,把数据都丢了,这是令我最为惊讶的地方。咱不用谈Oracle公司提供的先进的Exadata、Oracle cloud machine、Zero data loss machine…..(如果你想了解这些先进的东西,可以文章后面留下邮箱),就是传统的解决方案也很多。

 

 

方案一:用Oracle GoldenGate(或者同类产品)

 

 

我们在全国许多银行、交通、电信运营商已经成功实施、稳定运行5年以上了,最大的库每日单库日志增量1T左右。做好的秘诀是做好变更管控,每个月做切换演练。我知道很多企业做了之后,维护不好,然后数据不一致,最终成为摆设的。

 

方案二:用Oracle Active Data Guard(11g以后的版本适用)

 

 

适用ADG的好处是,不太需要关心源端的变更,而且是物理级别的复制,而且可以适用延迟恢复。事实上,如果条件允许,我们建议最好的容灾方案是ADG+OGG。

 

这些技术,对于现在的DBA或者说服务公司来说,都是小儿科了。重点的重点是流程,要投入资源保证灾备的可用、可靠:

 


 

Salesforce的遭遇显然不是个案,只因为她是云服务商中亭亭玉立(17岁)的一位,知名度大,所以为众人所知。君不见,微信群里经常会出现某某公司又在做非常规恢复了的消息。

 

如果你的数据库还没有做容灾或者没有做好,马上关注公众号:dbaplus,免费学习、咨询切磋~

 

作者介绍  杨志洪

  • 【DBAplus社群】联合发起人,新炬网络首席布道师;

  • 数据管理专家,拥有十余年电信、银行、保险等大型行业核心系统Oracle数据库运维支持经验,掌握ITIL运维体系,擅长端到端性能优化、复杂问题处理。现主要从事数据架构、高可用及容灾咨询服务;

  • Oracle ACE、OCM、《Oracle核心技术》译者。


本文来自云栖社区合作伙伴"DBAplus",原文发布时间:2016-05-14

目录
相关文章
|
4月前
|
存储 JSON 关系型数据库
【干货满满】解密 API 数据解析:从 JSON 到数据库存储的完整流程
本文详解电商API开发中JSON数据解析与数据库存储的全流程,涵盖数据提取、清洗、转换及优化策略,结合Python实战代码与主流数据库方案,助开发者构建高效、可靠的数据处理管道。
|
2月前
|
数据采集 关系型数据库 MySQL
python爬取数据存入数据库
Python爬虫结合Scrapy与SQLAlchemy,实现高效数据采集并存入MySQL/PostgreSQL/SQLite。通过ORM映射、连接池优化与批量提交,支持百万级数据高速写入,具备良好的可扩展性与稳定性。
|
2月前
|
人工智能 Java 关系型数据库
使用数据连接池进行数据库操作
使用数据连接池进行数据库操作
104 11
|
3月前
|
存储 数据管理 数据库
数据字典是什么?和数据库、数据仓库有什么关系?
在数据处理中,你是否常困惑于字段含义、指标计算或数据来源?数据字典正是解答这些问题的关键工具,它清晰定义数据的名称、类型、来源、计算方式等,服务于开发者、分析师和数据管理者。本文详解数据字典的定义、组成及其与数据库、数据仓库的关系,助你夯实数据基础。
数据字典是什么?和数据库、数据仓库有什么关系?
|
7月前
|
存储 缓存 数据库
数据库数据删除策略:硬删除vs软删除的最佳实践指南
在项目开发中,“删除”操作常见但方式多样,主要分为硬删除与软删除。硬删除直接从数据库移除数据,操作简单、高效,但不可恢复;适用于临时或敏感数据。软删除通过标记字段保留数据,支持恢复和审计,但增加查询复杂度与数据量;适合需追踪历史或可恢复的场景。两者各有优劣,实际开发中常结合使用以满足不同需求。
647 4
|
8月前
|
SQL 关系型数据库 数据库
【YashanDB知识库】OM仲裁节点故障后手工切换方案和yasom仲裁重新部署后重新纳管数据库集群方案
本文介绍了主备数据库集群的部署、OM仲裁故障切换及重新纳管的全过程。首先通过解压软件包并调整安装参数完成数据库集群部署,接着说明了在OM仲裁故障时的手动切换方案,包括关闭自动切换开关、登录备节点执行切换命令。最后详细描述了搭建新的yasom仲裁节点以重新纳管数据库集群的步骤,如生成配置文件、初始化进程、执行托管命令等,确保新旧系统无缝衔接,保障数据服务稳定性。
|
3月前
|
存储 关系型数据库 数据库
【赵渝强老师】PostgreSQL数据库的WAL日志与数据写入的过程
PostgreSQL中的WAL(预写日志)是保证数据完整性的关键技术。在数据修改前,系统会先将日志写入WAL,确保宕机时可通过日志恢复数据。它减少了磁盘I/O,提升了性能,并支持手动切换日志文件。WAL文件默认存储在pg_wal目录下,采用16进制命名规则。此外,PostgreSQL提供pg_waldump工具解析日志内容。
312 0
|
5月前
|
存储 SQL Java
数据存储使用文件还是数据库,哪个更合适?
数据库和文件系统各有优劣:数据库读写性能较低、结构 rigid,但具备计算能力和数据一致性保障;文件系统灵活易管理、读写高效,但缺乏计算能力且无法保证一致性。针对仅需高效存储与灵活管理的场景,文件系统更优,但其计算短板可通过开源工具 SPL(Structured Process Language)弥补。SPL 提供独立计算语法及高性能文件格式(如集文件、组表),支持复杂计算与多源混合查询,甚至可替代数据仓库。此外,SPL 易集成、支持热切换,大幅提升开发运维效率,是后数据库时代文件存储的理想补充方案。

热门文章

最新文章