upyun

关于又拍云12月5日故障的说明‏ 用户发展太快？不里处理速度还是另人满意的。 补偿好像没收到哈。 尊敬的又拍云用户： 我们为12月5日一组作图服务器故障导致部分图片上传失败给您带来的困扰深表抱歉，为避免您对此的担忧，我们向您坦诚这次故障的具体问题，让您了解这次意外的原因。 因又拍云存储平台的数据量急速上涨，云处理集群的压力也快速放大。为提前缓解数据放大带来的压力，提升作图服务器集群性能，12月5日凌晨，又拍云存储更新部署了一批新的作图服务器，并开启了作图服务的CPU亲缘性绑定支持，将服务绑定到了相应的CPU核心上。这个模式在非超线程环境的服务器中运行良好。但在这批开启了超线程支持的服务器上，随着当天下午请求高峰期的到来，逐渐出现不稳定现象，导致上层proxy超时，在该集群造成雪崩效应；由于我们初期对故障的定位偏差，在进行了系统内核降级、作图服务版本回滚等几项措施之后，未能快速缓解处理该问题，直至最后关闭超线程支持。 在新集群出现不稳定时，我们已紧急切换到了备用集群。但由于作图请求的雪崩效应，导致后备集群一直高负载运行，期间调用图片服务集群的图片上传、缩略图处理的不稳定状况持续了一段时间。在新集群关闭超线程支持、并确认状态正常，重新接入系统后，服务逐步恢复。 您信任我们，将您的数据放在了又拍云存储，出现这样的问题，我们非常的不安，也非常的抱歉，一次故障意味着给您带去了巨大的损失，这个损失我们不知该如何弥补，所以我们决定向您补偿一周的流量并延长一个月的存储使用期限。同时我们将对后续服务持续优化以保证更高的稳定性，避免类似意外的再次发生。我们再次恳请您的谅解。感谢您一直以来对又拍云的支持！ 杭州纬聚网络有限公司 2013.12.6

从去年开始用又拍云，收到的第一封故障信，总的来说，还是不错的，如果能像七牛一样，后付费就更好了 亲爱的又拍云存储用户： 2013年11月26日12时，又拍云监控系统报警，提示一部分新数据未能通过API接口上传。技术人员迅速排查，发现一台用于业务数据存储的MySQL服务器异常退出。技术人员当即启动应急预案，将这部分服务切换到灾备数据库，并进行了数据同步，至13时左右服务恢复正常。 服务恢复后，经过全面复检确认：该问题原因是又拍云的数据量级近期暴增，触发了MySQL Bug #63815 Reorganization May Make a Page Incompressible (http://bugs.mysql.com/bug.php?id=63815)，导致MySQL数据分块损坏，无法启动服务。现已对主库的数据进行了恢复和校验，并于27日凌晨已完成数据切换。 我们为未能及时做好此问题的防范，给一部分用户带来了影响，在此表示万分的抱歉。我们已于27日上午开始进行数据库的升级准备工作，并将尽快部署完成。在万分抱歉的同时，我们希望此问题不至于给您带来过多的困扰。云存储的发展始终伴随着承载更高数据的挑战，在这一挑战过程中必定伴随着一些没有经历大数据存储就很难知悉的问题。恳请大家相信，又拍云团队在8年的发展和磨练中，具备了对未知情况最大可能的预见能力和在最短时间内解决问题的能力。这次问题对于我们是一个深刻的教训，又拍云将着手进行持续的大数据的模拟，确保在更大数据量来临前，我们为大家做好了最安全的防范措施。 同时，也请这个故障时间段内未出现上传故障、未受到影响的各位用户放心，所有用户的数据外部访问和老数据的存储都未受影响，您的服务在此期间确保正常。如对上述情况有疑问，请您立即联系我们进行沟通，我们将竭尽全力协助您获得满意的结果。 最后，再一次向受此故障影响的各位支持又拍云的朋友们表示万分的歉意。