亚马逊AWS官方博客

让你的数据库流动起来 – 利用MySQL Binlog实现流式实时分析架构

数据分析特别是实时数据分析,已经越来越多的成为各行各业的分析要求与标准 – 例如,(新)零售行业可能希望通过­­线下POS数据与实时门店客流流量的进行实时结合与分析,实现商品销售,销量,总类等等的实时预测; 在线广告平台期望通过广告(Impression)总类,数据量以及基于时间的点击(Click)量,计算实时的广告转化率(Conversion Rate);物联网的用户想通过实时分析线下的状态设备与设备采集的数据,进行后台的计算与预判 – 例如做一些设备维修的提前预警(Predicative Failure Analysis)与线下用户的使用习惯;电商平台或者是在线媒体需要给终端用户提供个性化的实时推荐等等。 纵观这些业务系统,从数据流的角­­度看,往往数据架构可以分为前后端两个部分 – 前端的业务数据与日志收集系统(其中业务数据系统一般都是利用关系型数据库实现 –  例如 MySQL,PostgreSQL)与后端的数据分析与处理系统 (例如ElasticSearch 搜索引擎,Redshift数据仓库,基于S3的Hadoop系统 等等,或者基于Spark Stream的实时分析后端)。 “巧妇难为无米炊”,实时数据分析的首要条件是实现实时数据同步,即从上述前端系统到后端系统的数据同步。具体来讲包含两个要求(根据业务场景的不同,实时性会有差异)- 1) 实时 2) 异构数据源的增量同步。实时的要求容易理解 – 无非是前后端系统的实时数据ETL的过程,需要根据业务需求,越快越好。所谓异构数据源的增量同步是指,前端产生的增量数据(例如新增数据,删除数据,更新数据 – 主要是基于业务数据库的场景,日志相对简单,主要是随时间的增量数据)可以无缝的同步到后端的数据系统 – 例如ElasticSearch,S3或者Redshift等。 显然,这里的挑战主要是来自于异构数据源的数据ETL – 直白一点,就是怎么把MySQL(或者其他RDBMS)实时的同步到后端的各类异构数据系统。因为,MySQL的表结构的存储不能简单的通过复制操作实现数据同步。  业界典型的做法大概可以归纳为两类 – 1)通过应用程序双写的架构 (application dual-writes)  2) 利用流式架构实现数据同步,即基于流式数据的Change Data Caputre (CDC) 。 双写架构实现简单,利用应用逻辑实现,但是要保证数据一致性相对复杂(需要通过二阶段提交实现 – two phase commit),而且,架构扩展相对比较困难 – 例如增加新的数据源,数据库等。 利用流式数据重构数据,越来越成为很多用户与公司的实时数据处理的架构演化方向。 MySQL的Binlog,以日志方式记录数据变化,使这种异构数据源的实时同步成为可能。 今天,我们主要讨论的是如何利用MySQL的binlog实现流式数据同步。 MySQL […]

Read More

客户端直连S3实现分片续传思路与实践

Amazon S3是互联网存储解决方案,能让所有开发人员访问同一个具备可扩展性、可靠性、安全性和快速价廉的数据存储基础设施。Amazon S3 提供了一个简单 Web 服务接口,可用于随时在 互联网上的任何位置存储和检索任何数量的数据。开发人员可以利用Amazon提供的REST API接口,命令行接口或者支持不同语言的SDK访问S3服务. 同时S3对于上传功能的API提供也是非常丰富的,与此同时,很多客户对于S3的断点续传也有了很深入的需求,本篇博客将会介绍如何使用S3的Javascript SDK来实现客户端浏览器到S3的断点续传功能. 安全考量 首先我们需要度量在浏览器客户端直连上传到S3这个场景下的安全问题,我们是一定不能把我们的AccessKey暴露到客户端浏览器的,但是上传到S3的API一定要提供AccessKey和SecretKey,因此这里我们将会利用生成临时的AccessKey和SecretKey(结合有效期)的方式来保证客户端的上传,这里介绍一篇关于利用TVM (Token Vending Machine)来生成临时Key并上传S3的文章,本文主要探讨关于S3的分片上传和断点续传的知识点. Javascript SDK和S3 API简介 从整体编程语言架构的层面上来讲,AWS的各个语言的SDK都主要划分为上层和下层的API, 上层API主要是针对一些用户必要的功能利用下层API所作的一层封装,掌握了这个原则之后我们就可以合理的利用AWS的上层API看能否实现自身的需求. Javascript SDK文档总结 在掌握SDK之前,我们应该先对SDK的文档和大致的结构有一个了解,这样才能方便我们更好的使用SDK, 下面列出了SDK的官网入门连接和API参考文档. API参考文档: http://docs.aws.amazon.com/AWSJavaScriptSDK/latest/index.html S3 API参考文档: http://docs.aws.amazon.com/AWSJavaScriptSDK/latest/AWS/S3.html 构建SDK中的S3对象 首先,AWS的SDK都是先需要利用Credentials来构建对象的,这里我们构建S3的对象也是如此,但是请注意一定不能将自己的Key暴露在客户端或者提交到代码中,应该使用 TVM获取了Key之后再利用AWS.Credentials对象来构建S3的对象. 在构建S3对象时,也需要同时指定AWS的Region. 利用上层Javascript API构建简单的分片断点续传功能 接下来,我们一步一步的来创建上层API构建断点续传的实践. 1. 创建工程 这里我们以node.js平台的express来提供简单的静态服务. 本文不会涉及如何安装node.js,关于安装指南,可以参考官网nodejs.org 首先利用npm包管理器安装express模版生成器: npm install express-generator -g 完成后我们利用命令行生成项目: mkdir s3upload express –view=ejs 这里的–view=ejs主要指定ejs作为express的html模版引擎,方便我们的测试. 创建好之后的工程结构如下图: 2. 编写页面UI 这里我们通过引入<script […]

Read More

自动化部署服务——AWS CodeDeploy 快速入门

作为DevOps和微服务的深入践行者,Amazon在内部积累了许多持续集成、交付和部署的自动化工具和平台。其中, Apollo作为代码部署的自动化平台,每年进行超过5000万次部署。 为了能够让广大开发者和企业用户使用到功能丰富且久经考验的代码部署平台,在Apollo的经验基础上,AWS发布了自动化部署服务——CodeDeploy。 平台介绍 AWS CodeDeploy旨在帮助用户完成应用的快速部署,按照用户指定的策略将代码部署在一组EC2服务器上。用户策略可以包括集群部署速度、部署事件通知、警报处理策略等。此外,CodeDeploy还可以和弹性负载均衡(Elastic Load Balancer)、自动扩展组(Auto Scaling Group)等服务结合,完成无缝升级和动态部署。 为方便有效地组织部署任务,CodeDeploy设立了三个概念:应用(Application)、部署(Deployment),以及部署配置(Deployment Configuration)。 1)应用程序(Application) 应用程序是部署的核心,由部署组(Deployment Group)和代码修订(Revisions)组成。一个应用可以包含多个部署组,一个部署组又可以包含多台EC2服务器。同时,一个服务器也可以属于多个部署组,因为一个服务器可能同时运行多个应用。 1.1)部署组 创建或修改部署组时,如果添加EC2服务器,可以通过标签(Tag)对已有的EC2服务器进行筛选。所以,在创建EC2时一定要打上标签(Tag),便于在创建应用的部署组时找到对应业务的服务器。 此外,部署组还可以添加自动扩展组(Auto Scaling Group),以及用户自己机房的主机(On-Premise Instance)。 1.2)代码修订 代码修订保存了当前应用涉及到得所有代码,代码的存放位置可以在S3或Github。 如果用户自建代码托管,当需要部署时,可以在工作机上同步代码到本地,然后使用AWS命令行进行打包上传。 aws deploy push –application-name <MyAppName> \       –s3-location s3://<MyBucketName>/<MyNewAppBundleName> \       –source <PathToMyBundle> 上面的命令可以将运行目录下得代码打包上传到S3,同时显示在关联应用的代码修订一栏中。 2)部署(Deployment) 每一次部署都有唯一的ID标记,并保存所有信息,如代码来源、部署时间、目标服务器、部署结果等。并且针对每一台服务器,都可以详细查看部署过程中的事件(如下载程序、安装前检查、 程序启动、安装后检查等7个事件),以便追踪部署的各个步骤。当部署出错时,可以快速定位和排查。 3)部署配置(Deployment Configuration) 部署配置存放了一次部署的服务器台数或百分比,在发起部署时需要指定所需配置。CodeDeploy默认提供了三种配置:一次部署一台、一次部署一半数量的服务器,以及一次完成全部部署。部署发起后,CodeDeploy会按照上述策略进行工作,指导完成部署组内全部服务器的更新。 如果用户要自定义部署策略,建议使用命令行完成。比如下面的例子创建的配置就是一次完成20%的服务器部署。 aws deploy create-deployment-config –deployment-config-name ThreeQuartersHealthy –minimum-healthy-hosts type=FLEET_PERCENT,value=20 此外,CodeDeploy还可以管理物理主机(或第三方主机)。只要在物理主机上安装和配置CodeDeploy Agent,Agent向CodeDeploy注册完成后,CodeDeploy就可以像管理 EC2服务器一样在物理服务器上部署应用。 […]

Read More

手把手教你在FPGA实例上运行“Hello World”

前言 在4月19号的旧金山AWS技术峰会上,亚马逊CTO Werner Vogels宣布了多项AWS新功能,其中就包括众人期待已久的FPGA实例F1。 F1 实例配有最新的 16 nm Xilinx UltraScale Plus FPGA,目前有f1.2xlarge和f1.16xlarge两种类型,其中f1.2xlarge配备有1个FPGA卡, f1.16xlarge配备有8个FPGA卡。 使用 F1 实例部署硬件加速在许多高性能计算 (HPC) 应用程序中非常有用,可解决需要高带宽、增强型联网和较高计算能力的复杂科学、工程和业务问题。F1 实例尤其适用于有时间要求的应用程序,如临床基因组学、实时视频处理和财务风险分析。 因为这段时间都在学习神经网络,所以F1实例最吸引我的是在FPGA上部署神经网络模型,神经网络的前向计算以高频脉冲的方式同时发生在门电路构成的神经网络单元上,想想都让人激动。 不过FPGA这个东西确实太专业了,入门学习曲线不是一般的陡,启动F1实例运行一个简单的Hello World都需要折腾一番。 所以在这里记录一下自己启动F1实例运行Hello World的过程,供各位参考,希望可以让大家开始开始FPGA的旅程。 启动f1实例 f1实例的启动过程和一般的EC2启动过程类似,有关AWS账号的准备,EC2创建过程的细节请大家参考相关技术文档。以下只列出一些需要注意的地方。 测试时我选择了“弗吉尼亚北部”这个区域,也就是us-east-1区域。 启动f1实例时强烈推荐使用 AWS FPGA Developer AMI 镜像, FPGA Developer AMI 包括一个预先打包的工具开发环境,其中含有用于模拟 FPGA 设计、编译代码及构建和注册 AFI 的脚本和工具。 在启动实例的第一步,选择系统镜像的时候选择“AWS Marketplace”,然后搜索“FPGA”就可以找到FPGA Developer AMI, 该镜像在弗吉尼亚北部区域的ID为:ami-3afc6f2c,镜像选择界面截图如下。 启动过程中注意给你的实例指定一个IAM Role, 后续使用AWS CLI命令行工具的时候就需要配置静态的Access Key和Secret Key了。 还有就是安全组配置,缺省的22号端口保留打开状态,另外建议开3389端口,后续如果你希望使用远程连接的方式使用图形化界面需要用到这个端口。 还有一个不需要再强调的就是你启动的f1实例需要有公有IP。 系统登录 […]

Read More

带您玩转Lambda,轻松构建Serverless后台!

Amazon CTO Werner Vogels曾经在AWS re:Invent大会上提到: 如果把云计算理解成一个执行环境,那么,在这个环境里,函数(即业务逻辑的载体)+数据(即跟业务相关的输入与输出)就是应用的核心,有了Functions、Data、Event这三者,其它任何代码和框架,无非是整个应用的胶水和UI罢了。那么,最理想的情况就是用最少的时间写胶水,将更多的时间投入到核心应用的开发中,甚至,彻底实现整个软件栈的微服务化。 那么能不能做到呢?答案是肯定的。AWS Lambda也在这样的背景下应运而生了,其实在很多人眼里,Lambda是一个具有“革命性”的服务,我本人也非常喜欢Lambda这个服务,因为它给我的感觉是: 轻、快、高可用!能够快速将想法写成代码,并应用到生产,不需要关心底层基础设施的运维。接下来,让我们一起搭建一个serverless的后台! 【1】AWS Lambda怎么用? 怎么学习Lambda呢?让我们从一个简单的数学问题开始,10以内乘法和加法运算,获得随机的一个数字。代码有注释,如下: //Node.js尽量全使用严格模式 ‘use strict’; //利用console.log可以将日志自动打到CloudWatch里面 console.log(‘Loading function’); exports.handler = (event, context, callback) => {     //定义一个最小值为2     var min = 2;     //定义一个最大值为10     var max = 10;     //生成一个随机数,乘以最大值,再加上一个最小值     var generatedNumber = Math.floor(Math.random() * max) + min;     //利用callback回调,得到结果。     callback(null, generatedNumber); […]

Read More

使用Sqoop实现RDS MySQL到Redshift的数据同步

希腊有一个著名的谷堆悖论。“如果1粒谷子落地不能形成谷堆,2粒谷子落地不能形成谷堆,3粒谷子落地也不能形成谷堆,依此类推,无论多少粒谷子落地都不能形成谷堆。但是,事实并非如此。” 这个悖论说的,就是告诉我们量变产生质变,需要一个明显的分割线。如果说,量是一个量化的数据,质是一个结论的话。那么,数据分析做的,就是要分析量,从而引向“定性”、”定质”。定量的了解历史的规律(“质”),从而预测未来。 近几年,大数据风靡全球,越来越多的企业利用MapReduce,Hive,Spark等计算框架和工具来为自身的业务提供帮助,在AWS上,我们也提供了诸多的服务,帮助用户能够快速地构建起适合自身需求的大数据分析架构,其中,Amazon Redshift是性能优异并且完全托管的PB级别数据仓库服务,提供了标准SQL数据库访问接口,并且可以十分方便地与现有的主流商业智能数据分析工具整合,构建企业级数据仓库。 然而,大部分企业的核心数据都存储在关系型数据库中,如何能够有效地将这部分存量数据以及后续的增量数据导入Redshift中呢?本文介绍一种使用开源的Apache Sqoop工具,帮助我们轻松实现这一过程。 配置步骤: 第一步 准备工作 1.1 修改MySQL中的表结构 为了能够实现增量同步,需要在MySQL表中增加一列时间戳,该列能够自动记录行被插入更新的时间 为了能够实现同步删除操作,需要在MySQL表中增加一列删除记号列,应用对数据库的删除通过标记该列完成,而不是通过传统的delete语句,因为通常对于曾经存在过的数据,也有分析的意义 本例需要同步的表为country,orders,user,其中country表为Mycat中的全局表,在两台RDS mysql1和mysql2中都有全部信息,orders和user表为Mycat中的分片表,信息分布在RDS mysql1和mysql2中 mycat_sequence表是用于记录其他表自增字段信息的功能表,无需同步到Redshift中分析 执行如下语句添加两列 alter table country add ifdelete boolean NOT NULL default 0; alter table country add lastmodified TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMEST AMP; 1.2 创建EMR集群 注意勾选上Hive和Sqoop,同时目前AWS EMR最新的版本为5.4.0,其中对一些组件的版本进行了更新,不过Hive和Sqoop的版本与本文一致 注意选择相应的VPC和子网,子网需要有internet的路由方便之后ssh登入 选择登入的密钥对,Master安全组使用默认的ElasticMapReduce-master,不用修改 启动EMR集群后,修改Master节点的安全组,添加允许公网ssh访问 在EMR界面获取master节点ssh登入的信息 1.3 创建Redshift数据仓库 首先创建Redshift使用的安全组,放行所有源访问5439端口的权限 分别在cn-north-1a和cn-north-1b两个可用区中创建两个子网给Redshift使 用,由于之后会通过公网连接Redshift,这两个子网需要有到internet的路由 在Redshift中创建子网组,选上之前创建的两个子网组 创建Redshift参数组 […]

Read More

新上线!AWS CodeDeploy自动部署初相识

作为一个开发运维人员,您是否还在为: 1.    如何快速地将新版本应用部署到大批量服务器,无论其是云服务器EC2还是本地服务器? 2.    如何在部署过程中消除停机时间? 3.    如何规避易于出错的手工操作? 4.    在遇到问题时,如何快速回滚?并及时向您发送通知? 今天,我们很高兴地宣布:AWS的CodeDeploy服务能够助您一臂之力!它能够协助您将应用程序部署到 Amazon EC2 实例和/或非 Amazon EC2 实例的物理或虚拟设备。应用程序包扩:代码、Web 和配置文件、可执行文件、程序包、脚本等可部署的内容。AWS CodeDeploy 支持从 Amazon S3 存储桶和 GitHub 存储库部署应用程序。 您无需更改现有代码即可使用 AWS CodeDeploy。您可以使用 AWS CodeDeploy 控制跨 Amazon EC2 实例部署的速度,并定义要在每个阶段采取的操作。 AWS CodeDeploy 具备下列优势: 自动部署。AWS CodeDeploy 可完全自动部署应用程序,并随您的基础设施进行扩展,让您能够部署到数千个实例。 最大程度减少停机时间。AWS CodeDeploy 可以最大程度地提高应用程序的可用性。支持滚动部署和蓝/绿部署模式。并根据您配置的规则跟踪应用程序运行状况。 停止并回滚。出现错误时,您可以自动或手动停止和回滚部署。 易于采用。AWS CodeDeploy 与平台无关,适用于任何应用程序。您可以轻松重用设置代码。AWS CodeDeploy 还能与您的软件发布过程或持续交付工具链集成。 AWS CodeDeploy 支持如下2种部署模式 就地部署:对部署组中的实例依次执行脱机操作/更新应用/恢复联机的操作,完成滚动部署。 蓝绿部署:创建一组新的替换实例,并安装新版本的应用程序。成功后,切换流量到这些新实例,删除旧实例,完成部署。AWS CodeDeploy 运行您在切换流量之前,对新版本应用程序进行测试。如果发现问题,您可以快速回滚到旧版本。 […]

Read More

CrowdTangle经验谈:如何立足AWS构建SaaS解决方案

马曾经是种极为重要的交通工具。 如果大家打算在150年前提供信使服务,就会意味着使用马匹作为交通工具能够带来远超步行的交付效率。当然,大家也必须雇专人照顾马匹、购买饲料并清理马厩——但这一切在马匹带来的速度优势面前简直不值一提。随着时间的推移,饲养马匹带来的相关技能将使得大家建立起自己的完整业务系统,从而更为高效地处理各类突发事件。 然而接下来汽车出现了,马匹作为交通工具的使命开始逐步被历史所淘汰。 当然,这一过程并非一蹴而就。第一辆行驶在街头的汽车并不会让您立刻破产。而且尽管汽车已经越来越多被主流所接受,大家仍然拥有一定的比较优势,证明并无转投汽车邮递方向的必要。然而,一旦以车辆为主要工具的同类企业开始出现,您的大麻烦将很快由可能变为现实。 在CrowdTangle公司,我们构建起一系列全球领先的工具选项,旨在帮助人们对社交媒体中的信息动态加以追踪。我们拥有一支工程师与才会人员团队,负责引导各大媒体企业、大联盟队伍以及其他用户找到其最关心的实时信息。更重要的是,我们的公司建立于2011年,并在过去五年中一直在使用AWS。我们过去曾经、未来也将坚信AWS能够作为我们建立完整业务的稳固基石。 AWS对我们而言就如汽车一般。 这样的比喻看似夸张,但其实非常客观。立足于AWS,我们得以建立起一套完全不同于以往五年的组织形式。具体来讲,AWS在四大主要方面对我们产生了影响:业务模式、人员聘用、规划以及速度——当然,这一切总结起来都可以归纳为“成本”二字,进而推衍为“生存”。 首先是商业模式。当最初建立这家企业时,我们并没有考虑利用物理介质承载我们的软件,亦没有考虑建立自己的基础设施。相反,我们选择了软件即服务(简称SaaS)这一模式,并借此获得了大量直接性收益:我们能够允许用户单纯通过访问网站的方式试用我们的产品; 我们能够在一天之内发布数十项功能与修复方案; 我们亦能够确保每位用户皆具备同样的受控使用体验。不过更重要的是,要交付业务产品,我们过去必须在起步时即承担沉重的资本支出。但在AWS的帮助下,我们无需此类初始成本即可让SaaS成为一种可行的发展选择,并在业务增长的同时不断扩大规模。 其次是人员招聘。AWS提供Amazon关系数据库服务(简称Amazon RDS),这是一项托管数据库服务,意味着我们不再需要雇用数据库管理员即可将该服务直接交付开发者使用(且使用英特尔至强E5处理器,代表性能质量亦可得到保证)。另外,AWS还拥有Elastic Beanstalk,这项服务允许我们更为轻松地在AWS之上部署自有应用程序,从而为前端及后端服务器设置独立环境并以一键式操作对其分别加以扩展。再有,AWS的托管NoSQL数据库服务Amazon DynamoDB使得我们不再需要四名全职工程师专门负责数据库的连接与运转。我们拥有TB级别的实时数据,可在个位数毫秒之内完成响应,而且在我个人看来该服务完全能够实现自我维护。在此基础之上,我的团队能够专注于考量如何推动业务发展,而不再需要为保持系统正常运作而分神。 第三项为规划。如果大家仍然生活在以马匹作为主要交通工具的时代,那么资源采购模式无疑是根据自身能力尽可能多地进行设备买入,直到您清楚地发现当前资本支出已经超过企业的承受能力。另外,大家需要研究各类新型设备、联系供应商、投入大量资金、等待设备发货、进行现场安装,并在其性能无法满足需求时尝试转售以收回一点成本。但在汽车时代下,如果我认为企业需要更多设备资源,则可在很短时间之内申请一项实例,并按小时为这一立即可用的资源支付成本。在相关任务完成之后,我可以关闭该实例并不再承担任何后续成本。更重要的是,实例本身的具体规模并不重要——我们完全可以根据需求申请与之匹配的资源容量。 最后,我想聊聊速度这个话题。由于我们选择在AWS之上建立自己的解决方案,因此我们得以拥有一支敏捷、能够快速交付资源并主要关注项目本身而非被迫思考系统维护工作的团队。我们不仅能够在业务范围内的项目进行快速转换,同时亦可以低成本方式实现探索性思路的实验性实施。每个新项目既可能中途失败,亦可能成为我们的下一款百万美元级产品——且二者在初始阶段完全相同,包括建立设想、克隆现有环境、建立项目分支、以实验性方式向客户交付并在获得好评后全面推向市场。 我们最近发现系统聚合部分的处理速度比预期更慢,因此我们开始尝试将其转移至Amazon Redshift。为了实现这一目标,我们首先申请了一个小型Redshift实例(注:未进行规划),并在完成初步测试之后将整体生产数据库复制到Redshift当中(注:研发速度)。“生产”性实验证明这一举措确实能够带来可观收益,因此我们为自己的系统建立起一整套辅助Amazon Kinesis-Redshift托管通道(注:尽管新增系统,但未招聘任何额外人员),而此举最终让我们获得了此前根本无法想象的新产品研发能力。那么这一切在传统模式下需要耗费多少成本?需要采取怎样的执行方式?项目中的各项因素能否拥有受控规模以保证不致造成巨大损失?我们总是从小笔投入着手,而正是这一点让我们能够保持所在业务领域的领导地位。 毫无疑问,未来的竞争对手必然同样借助汽车作为业务基础——在这样的历史背景下,单凭马匹如何在对抗中取胜? 欲了解更多关于CrowdTangle公司的信息,请点击此处参阅我们的官方网站。

Read More

Amazon EBS弹性卷修改实践

简介 在应用飞速的更新换代、数据量高速增长的今天,AWS的客户对EC2的块存储需求是随时间而改变的,很可能会多次需求增加容量或改变性能特性。在当今的24×7(全天候不间断)操作模式下,服务器没有停机的余地。因此,客户希望在应用不离线或不影响正常操作的情况下进行更改。换句话说,我们的客户希望他们的EBS卷更有弹性! 在2017年2月13日,AWS全球推出了一个新的EBS功能,称为弹性卷(Elastic Volumes),并使其适用于当前所有EC2实例可生成的EBS卷。在2017年2月17日,AWS中国区可以使用这项新功能。通过这一项功能,可以在EBS卷正在使用时增加卷的大小,调整性能或更改卷类型,并能在这些更改生效之前继续使用应用程序等运行在EC2实例上的程序功能。这一新功能的更新将大大简化企业或个人用户的许多规划管理,可以通过简单的API调用来及时更改存储基础架构,取代传统的需要几周或几个月的配置周期。 使用场景 1. 卷类型更改。在项目初期,为了更快部署应用,您初步设置块存储使用通用SSD卷(General Purpose SSD volumes),在获得一些使用经验后,发现吞吐量优化卷(Throughput Optimized volumes)是更好的选择,这时您只需要更改卷的类型就能够轻松解决问题。 2. IOPS性能调整。假设您在IOPS卷中运行一个关系型数据库,并设置它处理正常范围内的数据读写,由于每个月最后几天数据读写突增到正常水平的10倍,您只需要通过弹性卷短时间内获取更强大的读写配置来处理每月最高的数据读写,然后回调至正常配置来处理正常范围内的数据读写。 3. 卷存储增加。您获取了一个卷使用警告,提示您当前使用存储空间超过90%,这时您可以增加卷的大小,并扩展文件系统来匹配,弹性卷将以完全自动化的方式处理请求而不用停止EC2实例。 适用范围 AWS全部区域,包括海外和中国北京区域。 修改限制 所有卷大小的修改只能增加卷的大小!为了保护所有EBS卷中的数据,弹性卷修改仅允许增加卷的大小。如果您想将当前卷大小改小,可以先通过数据迁移工具将EBS卷中的数据移动到较小的卷,再将原来的卷删除。 1. 通用SSD卷:卷大小最小为1GiB,最大为16384GiB(16TiB);IOPS性能无法修改,最小为100,最大为10000,在最大最小值范围内为卷大小的3倍(卷大小单位为GiB),IOPS超频可达到3000。 2. 预配置IOPS SSD (io1):卷大小最小为4GiB,最大为16384GiB;IOPS性能可以修改,最小为100,最大为20000,在最大最小值范围内最大可调整至卷大小的50倍(卷大小单位为GiB)。 3. Cold HDD (sc1):卷大小最小为500GiB,最大为16384GiB;Cold HDD (sc1) 卷提供低成本的磁性存储,该存储以吞吐量而不是 IOPS 定义性能。此处无法做任何更改。 4. 吞吐量优化卷:卷大小最小为500GiB,最大为16384GiB;吞吐量优化卷提供低成本的磁性存储,该存储以吞吐量而不是IOPS定义性能。 5. 旧版磁介质卷:无法修改。磁介质是上一代卷。对于新应用程序,我们建议使用较新的卷类型。 数据截至至2017年2月17日,具体数据以AWS实时数据为准。更多有关EBS卷的相关信息,请查阅Amazon EBS卷类型。 操作指南 您能通过AWS管理控制台、API调用或从AWS命令行界面(CLI)管理使用所有功能。下面将介绍AWS管理控制台对弹性卷修改的操作指南,获取更多API调用及命令行界面的操作方式,请访问AWS文档。 修改本身不收取任何费用,您只需按实际使用量付费。更多定价信息,请访问EBS定价。 一、引导卷(根分区)修改 登陆AWS中国区,并选择服务EC2,打开EC2面板后,鼠标左击点选左侧导航栏的“卷”。 打开卷面板后,选择您要调整的卷,点选“操作”打开下拉菜单,在下拉菜单中点选“Modify Volume”。 然后可以对卷类型、大小和预配置的IOPS(如果适用的话)进行任何符合需求的更改,修改检查完后,点击Modify按钮。 注意卷大小不能减小。 注意预配置IOPS SSD卷的IOPS值不能大于卷大小的50倍(卷大小单位GiB)。 在修改确认页面点击“Yes”按钮。 卷修改正在进行,请稍等一会儿。 卷修改完成。 […]

Read More

利用Mycat中间件实现RDS MySQL的分库分表及读写分离功能

随着移动互联网的兴起和大数据的蓬勃发展,系统的数据量正呈几何倍数增长,系统的压力也越来越大,这时最容易出现的问题就是服务器繁忙,我们可以通过增加服务器及改造系统来缓解压力,然后采用负载均衡、动静分离、缓存系统来提高系统的吞吐量。然而,当数据量的增长达到一定程度的时候,增加应用服务器并不能明显地提高系统的效率,因为所有压力都会传导到数据库层面,而大多数系统都是用一个数据库来存储和管理系统数据的,因而一个支持高性能、高并发并且易于扩展的数据库系统变的尤为重要。 Amazon RDS是AWS上托管的关系型数据库服务,目前支持业界主流的MySQL、Oracle、SQL Server、PostgreSQL、MariaDB引擎及AWS提供的Aurora,通过多可用区主备及读副本等技术,能够支持绝大部分的应用场景。 对于更大容量的数据库,可以使用Amazon Aurora,Aurora是一个关系型数据库引擎,结合了高端商用数据库的速度和可用性,同时还具有开源数据库的简单性和成本效益。Amazon Aurora 的设计与 MySQL 5.6 及PostgreSQL 9.6.1兼容,它提供的性能比同一硬件上运行的标准 MySQL 最多高达五倍,比PostgreSQL最多高达二倍。 下表是单个数据库实例能够支持的存储容量大小: RDS数据库引擎 存储容量 MySQL 6TB Oracle 6TB PostgreSQL 6TB MariaDB 6TB SQL Server 4TB Aurora 64TB 不过由于Aurora目前并未在所有region提供,比如中国北京,同时支持的引擎有限,对于中国区用户及使用其他数据库引擎的用户,不得不考虑其他的解决方案。随着近年来海量数据存储、并行计算、异构数据互联等一系列新技术在市场上不断出现。相信数据库行业的很多从业者都对传统关系型数据库的单点故障及容量问题头疼不已,而数据库分库分表也早已成为解决此类问题的基础。 本文要介绍的Mycat是一款面向企业级应用的开源数据库中间件产品,支持事务、ACID,能够对接Oracle、MySQL、DB2、SQL Server、MongoDB、SequoiaDB等数据库,支持透明的读写分离机制,支持各种MySQL集群,包括标准的主从异步集群、MySQL Galera Cluster多主同步集群等,通过大表水平分片方式支持100亿级大表的分布式存储和秒级的并行查询能力,内建数据库集群故障切换机制,实现自动切换,可满足大部分应用的高可用性要求。 配置步骤: 第一步 创建RDS数据库实例 创建一个RDS将会使用的参数组mycat 在分库分表的情况下,Mycat可以通过如下几种方式保证自增主键的全局唯 一: 1. 本地文件方式 在sequence_conf.properties文件中设置主键的当前值,最小值和最大值 2. 数据库方式 在其中一个 MySQL 节点中建立一张表,存放 sequence 的名称,当前值,步长 等信息,并通过存储过程修改更新信息 3. 本地时间戳方式 4. […]

Read More