• 关于 polarDB云服务 的搜索结果

回答

PolarDB支持从RDS MySQL一键克隆数据到新的PolarDB MySQL集群。 前提条件 源RDS实例版本为RDS MySQL 5.6高可用版。 源RDS实例未开启TDE和SSL。 源RDS实例的表存储引擎为InnoDB。 如果RDS处于高安全模式(数据库代理模式),需要创建有高权限账号(请参见创建高权限账号),或者切换到高性能模式(参见【重要】RDS网络链路升级说明),才能进行一键克隆。查看数据库模式 背景信息 PolarDB是阿里云自研的下一代关系型云数据库,主要优势如下: 存储容量高:最高可达100TB。 性能高:最高可以提升至MySQL的6倍。 Serverless存储:存储容量无需提前购买,自动扩缩容,按使用量计费。 临时升配:临时升级规格,轻松应对短期的业务高峰。 详情请参见产品优势。 一键克隆功能将会新建一个与源RDS实例的数据相同的PolarDB集群,PolarDB集群包含源RDS实例的账号、数据库、IP白名单和必要的参数。源RDS实例的增量数据不会同步到PolarDB集群。 说明 如果需要在新建PolarDB集群的同时,使源RDS实例的增量数据实时同步到PolarDB集群,即实现平滑迁移(不停机迁移),请参见一键升级RDS MySQL到PolarDB MySQL。 一键克隆的功能亮点 免费 克隆过程数据0丢失 一键克隆的操作步骤 登录PolarDB控制台。 单击创建新集群。 选择包年包月或按量付费页签。 设置以下参数。 参数 说明 地域 源RDS MySQL实例所在地域。 说明 克隆的PolarDB集群也在此地域。 创建方式 集群的创建方式: 默认创建:创建一个全新的PolarDB集群。 从RDS克隆:基于所选的RDS实例,克隆一个数据完全一样的PolarDB集群。 从RDS迁移:先从RDS实例克隆一个PolarDB集群,同时保持同步。默认开启新集群的Binlog。 这里选择从RDS克隆。 源RDS引擎 源RDS实例的引擎类型,不可变更。 源RDS版本 源RDS实例的版本,不可变更。 源RDS实例 可选的源RDS实例,不包括只读实例。 可用区 可用区是地域中的一个独立物理区域,不同可用区之间没有实质性区别。 您可以选择将PolarDB集群与ECS创建在同一可用区或不同的可用区。 网络类型 PolarDB集群的网络类型,不可变更。 VPC网络 VPC交换机 PolarDB集群所属的VPC和虚拟交换机。请确保PolarDB集群与需要连接的ECS创建于同一个VPC,否则它们无法通过内网互通,无法发挥最佳性能。 数据库引擎 PolarDB集群的数据库引擎,不可变更。 节点规格 按需选择,建议不低于源RDS实例规格。所有PolarDB节点均为独享型,性能稳定可靠。详情请参见规格与定价。 节点个数 无需选择。系统将自动创建一个与主节点规格相同的只读节点。 存储费用 无需选择容量,根据实际数据使用量按小时计费。详情请参见规格与定价。 集群名称 填写集群名称用于区分业务用途。如果留空,系统将自动生成一个集群名称。创建集群后还可以修改。 设置购买时长(仅针对包年包月集群),然后单击右侧的立即购买。 确认订单信息,阅读和勾选服务协议,单击去开通。 常见问题 从RDS克隆会影响源RDS实例吗? 答:不会影响源RDS实例的正常运行。 相关API API 描述 CreateDBCluster 创建PolarDB集群。 说明 一键克隆时,参数CreationOption取值需要为CloneFromRDS。 后续步骤 请尽快将应用的数据库连接地址修改为PolarDB的地址,详情请参见查看连接地址。

游客yl2rjx5yxwcam 2020-03-08 14:02:52 0 浏览量 回答数 0

回答

PolarDB支持将RDS MySQL一键升级为PolarDB MySQL。 前提条件 源RDS实例版本为RDS MySQL 5.6高可用版。 源RDS实例未开启TDE和SSL。 源RDS实例的表存储引擎为InnoDB。 如果RDS处于高安全模式(数据库代理模式),需要创建有高权限账号(请参见创建高权限账号),或者切换到高性能模式(参见【重要】RDS网络链路升级说明),才能进行一键升级。查看数据库模式 背景信息 PolarDB是阿里云自研的下一代关系型云数据库,主要优势如下: 存储容量高:最高可达100TB。 性能高:最高可以提升至MySQL的6倍。 Serverless存储:存储容量无需提前购买,自动扩缩容,按使用量计费。 临时升配:临时升级规格,轻松应对短期的业务高峰。 详情请参见产品优势。 一键升级功能可以将RDS MySQL一键升级为PolarDB MySQL,升级后PolarDB集群包含源RDS实例的账号、数据库、IP白名单和必要的参数。 一键升级的功能亮点 迁移完全免费。 迁移过程数据0丢失。 支持增量迁移,停机时间小于10分钟。 支持回滚,迁移失败可以在10分钟内恢复。 迁移流程 参见从RDS迁移的说明,创建一个与源RDS实例数据相同的PolarDB集群,源RDS实例的增量数据会实时同步到该PolarDB集群。 说明 需要在7天内修改应用端的数据库地址为PolarDB地址,确认业务正常,以及单击完成迁移。单击完成迁移会中断RDS和PolarDB之间的数据同步。 单击迁移切换。该操作将源RDS实例修改为只读,将PolarDB集群修改为可读可写,PolarDB的增量数据会实时同步到RDS。修改数据库连接地址。具体操作请参见迁移切换。 说明 迁移切换后,也可以选择迁移回滚。 完成迁移。 注意事项 迁移只能在相同地域内进行。 源RDS实例在迁移时不能修改参数。 从RDS迁移 本操作将创建一个与源RDS实例数据相同的PolarDB集群,源RDS实例的增量数据会实时同步到该PolarDB集群。 登录PolarDB控制台。 单击创建新集群。 选择包年包月或按量付费页签。 设置以下参数。 参数 说明 地域 源RDS MySQL实例所在地域。 说明 新建的PolarDB集群也在此地域。 创建方式 选择从RDS迁移。 即从RDS实例克隆一个PolarDB集群,同时保持数据同步。默认开启新集群的Binlog。 源RDS引擎 源RDS实例的引擎类型,不可变更。 源RDS版本 源RDS实例的版本,不可变更。 源RDS实例 可选的源RDS实例,不包括只读实例。 可用区 可用区是地域中的一个独立物理区域,不同可用区之间没有实质性区别。 您可以选择将PolarDB集群与ECS创建在同一可用区或不同的可用区。 网络类型 PolarDB集群的网络类型,不可变更。 VPC网络 VPC交换机 PolarDB集群所属的VPC和虚拟交换机。请确保PolarDB集群与需要连接的ECS创建于同一个VPC,否则它们无法通过内网互通,无法发挥最佳性能。 兼容性 PolarDB集群的数据库引擎,不可变更。 节点规格 按需选择,建议不低于源RDS实例规格。所有PolarDB节点均为独享型,性能稳定可靠。详情请参见规格与定价。 节点个数 无需选择。系统将自动创建一个与主节点规格相同的只读节点。 存储费用 无需选择容量,根据实际数据使用量按小时计费。详情请参见规格与定价。 设置购买时长(仅针对包年包月集群),然后单击右侧的立即购买。 确认订单信息,阅读和勾选服务协议,单击去开通,完成支付。 进入PolarDB控制台,查看新建的PolarDB集群的状态。 说明 集群创建后开始从RDS实例同步数据,7 天内需要完成修改数据库连接地址以及完成迁移操作。超过7天将自动关闭迁移功能。 您可以在此步骤选择取消迁移,相关影响请参见迁移常见问题。 迁移切换 满足以下条件后,您可以进行迁移切换,然后修改应用里的数据库连接地址。 已完成从RDS迁移的操作。 复制延迟小于60秒。基本信息 进入PolarDB控制台。 找到目标集群,单击集群的ID。 在基本信息页面单击迁移切换,在弹出的对话框中单击确定。本操作将源RDS实例修改为只读,将PolarDB集群修改为可读可写,同时会将PolarDB集群的新增数据同步到RDS实例。迁移切换 说明 数据同步的延迟超过60秒时无法进行迁移切换。 切换过程一般小于5分钟。 刷新页面,当PolarDB读写状态显示为读写后,尽快修改应用里的数据库连接地址。刷新 说明 迁移切换完成后,也可以选择迁移回滚。 完成迁移 从RDS迁移后,需要在7天内修改数据库连接地址以及单击完成迁移。该操作将中断PolarDB集群和RDS实例间的数据同步。 警告 由于本操作将中断PolarDB集群和RDS实例间的数据同步,不再提供迁移回滚功能,建议您使用一段时间PolarDB集群,确认正常后再执行本操作。 进入PolarDB控制台。 找到目标集群,单击集群的ID。 在基本信息页面,单击完成迁移,在弹出的对话框中单击确定。完成迁移完成迁移确定 说明 单击确定后,系统将在约2分钟内中断同步关系,期间完成迁移按钮不会消失,请勿重复单击。 您可以选择是否关闭PolarDB集群的Binlog。关闭Binlog会带来少量的写入性能提升,但需要重启PolarDB。 如果不再需要源RDS实例,可以释放实例。 迁移回滚 在完成迁移前,如果您发现数据存在异常等问题,可以进行回滚操作,快速恢复至迁移前的状态(RDS实例为可读可写,PolarDB集群为只读,同时会将RDS实例的数据同步到PolarDB集群)。 进入PolarDB控制台。 找到目标集群,单击集群的ID。 在基本信息页面单击迁移回滚,在弹出的对话框中单击确定。迁移回滚 说明 单击确定后RDS实例为可读可写,PolarDB集群为只读,同时会将RDS实例的数据同步到PolarDB集群。当源RDS读写状态显示为读写后,请尽快修改应用里的数据库连接地址为RDS连接地址。 迁移常见问题 从RDS迁移会影响源RDS实例吗? 答:不会影响源RDS实例的正常运行。 平滑迁移对业务有影响吗? 答:平滑迁移能够保证迁移过程不丢失数据,停机时间小于10分钟,如果有需要还可以进行回滚。 取消迁移会有什么影响? 答:取消迁移后,源RDS实例可以修改参数;PolarDB集群恢复可读可写,且数据不会释放。手动取消时可以选择是否关闭PolarDB集群的Binlog,自动取消时不会关闭。

游客yl2rjx5yxwcam 2020-03-08 14:01:57 0 浏览量 回答数 0

问题

POLARDB概述

云栖大讲堂 2019-12-01 21:31:55 901 浏览量 回答数 0

新用户福利专场,云服务器ECS低至102元/年

新用户专场,1核2G 102元/年起,2核4G 699.8元/年起

问题

云数据库PolarDB的应用场景

云栖大讲堂 2019-12-01 21:31:57 1269 浏览量 回答数 0

问题

云数据库PolarDB的产品架构

云栖大讲堂 2019-12-01 21:31:56 1261 浏览量 回答数 0

问题

云数据库PolarDB的产品优势

云栖大讲堂 2019-12-01 21:31:57 1208 浏览量 回答数 0

回答

对于数据复制需求,很容易混淆数据迁移、同步、恢复这三个概念,本文介绍这三个概念的区别,方便您清楚认知自己的需求,并提供多种方案,可满足您的上云、迁云、同步、恢复等业务需求。 数据迁移/同步/恢复区别 数据迁移和恢复的异同 数据迁移和恢复都可以将数据复制到新实例,但是它们之间还有一定的区别: 数据迁移主要用于上云迁移,通过数据传输服务DTS将本地数据库/ECS上的自建数据库/第三方云数据库迁移至阿里云数据库,也可以从阿里云迁移至自建数据库。 数据恢复是通过数据备份和日志备份进行恢复,可以将某个备份集的数据恢复到实例,也可以通过备份集和日志备份将数据恢复到某个时间点。 数据迁移和恢复可以互补以实现更多功能,例如恢复数据到新实例后再通过DTS迁移回原实例,可以避免修改应用程序连接地址。 说明 控制台提供的恢复功能可以满足用户的大部分恢复需求,同时覆盖了部分迁移数据的需求(例如不要求增量迁移)。 数据迁移和同步的区别 数据迁移主要用于上云迁移,在勾选增量迁移时,可以实现数据同步的部分功能,但是不如数据同步灵活,例如不支持在线修改同步对象、不支持双向同步等。数据迁移属于一次性任务,迁移完成后即可释放实例。 数据同步主要用于两个数据源之间的数据实时同步,适用于异地多活、数据灾备、跨境数据同步、查询与报表分流、云BI及实时数据仓库等场景。它属于持续性任务,任务创建后会一直同步数据,保持数据源和数据目标的数据一致性。 数据迁移 适用场景 文档链接 (迁移上云)自建数据库迁移至RDS MySQL 从自建MySQL迁移至RDS MySQL 从通过专线/VPN网关/智能网关接入的自建MySQL迁移至RDS MySQL 从通过专线接入的自建MySQL迁移至其他云账号下的RDS MySQL 从自建DB2迁移至RDS MySQL 使用mysqldump迁移MySQL数据 从自建Oracle迁移至RDS MySQL RDS MySQL迁移至POLARDB 一键升级RDS MySQL到PolarDB MySQL 一键克隆RDS MySQL到POLARDB for MySQL 将第三方云数据库迁移至RDS MySQL 从Amazon RDS MySQL迁移至阿里云 从Amazon RDS Oracle迁移至阿里云RDS MySQL 从Amazon Aurora MySQL迁移至阿里云 从腾讯云MySQL迁移至阿里云 Google Cloud SQL的MySQL数据库迁移到阿里云 百度云MySQL数据库迁移到阿里云 华为云MySQL数据库迁移到阿里云 RDS实例间的数据库迁移 RDS实例间的数据迁移 不同RDS实例下库名不同的数据库之间的数据迁移 使用DTS跨阿里云账号迁移RDS数据 单个RDS实例内的数据迁移 RDS实例内不同数据库之间的数据迁移 将RDS MySQL数据迁移至自建MySQL数据库 从RDS MySQL迁移至自建MySQL 数据同步 适用场景 文档链接 MySQL间数据同步 RDS MySQL实例间的双向同步 RDS MySQL实例间的单向同步 从ECS上的自建MySQL同步至RDS MySQL 从通过专线/VPN网关/智能网关接入的自建MySQL同步至RDS MySQL 不同阿里云账号下RDS MySQL实例间的数据同步 从RDS MySQL同步至PolarDB MySQL 从RDS MySQL同步至通过专线/VPN网关/智能网关接入的自建MySQL MySQL数据同步至其他数据库 从RDS MySQL同步到AnalyticDB for MySQL 从RDS MySQL同步至AnalyticDB for PostgreSQL 从RDS MySQL同步至DataHub 从RDS MySQL同步至MaxCompute 从RDS MySQL同步至自建Kafka集群 数据恢复 适用场景 文档链接 RDS MySQL数据恢复至新实例/原实例 恢复MySQL数据 MySQL单库单表恢复 跨地域恢复 RDS MySQL数据恢复至自建数据库 RDS MySQL 物理备份文件恢复到自建数据库 RDS MySQL逻辑备份文件恢复到自建数据库 说明 如果实例还未释放或者对数据时间点没有要求,建议使用DTS从RDS MySQL迁移至自建MySQL。

游客yl2rjx5yxwcam 2020-03-09 10:46:05 0 浏览量 回答数 0

问题

最流行的关系型数据库 是如何在云端打造的

福利达人 2019-12-01 21:19:53 401 浏览量 回答数 0

问题

阿里云与MariaDB达成战略合作 推出云数据库RDS 企业级MariaDB

青蛙跳 2019-12-01 21:45:11 4318 浏览量 回答数 0

问题

Java,单机服务器如何充分利用服务器性能,达到最大并发量?

因为相信,所以看见。 2020-05-23 11:54:05 6 浏览量 回答数 0

问题

IT人必看!2018年上半年云栖大会300份干货免费开放!— 深圳峰会

游客886 2019-12-01 21:14:33 9846 浏览量 回答数 2

问题

Java,单机服务器如何充分利用服务器性能,达到最大并发量?:报错

kun坤 2020-06-07 09:02:41 0 浏览量 回答数 1

问题

南康开诊断证明-rgw专有云、混合云、边缘云

游客5k2abgdj3m2ti 2019-12-01 22:08:38 2 浏览量 回答数 0

问题

【精品问答】带你进入数据库领域

谙忆 2020-04-07 20:45:48 12 浏览量 回答数 1

问题

大数据时代——数据存储技术百问

yq传送门 2019-12-01 20:27:42 31965 浏览量 回答数 35

回答

前言 本文旨在通过 快速部署一个 wordpress 网站到阿里云 函数计算 平台 这个示例来展示 serverless web 新的开发模式, 包括 FUN 工具一键初始化 NAS, 同步网站到 NAS, 一键部署等能力, 展现函数计算的开发敏捷特性、自动弹性伸缩能力、免运维和完善的监控设施。 相关参考文档: https://yq.aliyun.com/articles/640912 1.1 DEMO 概述 DEMO 示例效果入口: http://hz.mofangdegisn.cn 账号: fc-test-user 密码: fc-test-pwd DEMO 示例工程地址: fc-wordpress 开通服务 免费开通函数计算, 按量付费,函数计算有很大的免费额度。 免费开通文件存储服务NAS, 按量付费 1.2 解决方案 image 如上图所示, 当多个用户通过对外提供的 url 访问web服务的时候,每秒的请求几百上千都没有关系, 函数计算平台会自动伸缩, 提供足够的执行实例来响应用户的请求, 同时函数计算提供了完善的监控设施来监控您的函数运行情况。 1.3 Serverless 方案与传统自建 web 方案对比 ITEM 成本 稳定性 基于 VM 方案 使用 ecs.t5-lc1m1.small, 22.8元/月 服务器和数据库在同一台VM, 均无主备容灾,同时该规格的主机本身性能弱 轻量应用服务器 60元/月(1vCPU 1GB 1Mbps 20GB[ssd]) 服务器和数据库在同一台VM, 均无主备容灾,同时该规格的主机本身性能弱 函数计算 sqlite3 版本约为 1元/月 mysql 版本大约 26元/月 高 函数计算完整费用详情: 每月前 100 万次函数调用免费, 每月前 400000(GB*秒) 费用免费, 函数的内存可以设置为 128M 或者 256M, 因此对于一个一个月访问量低于 100 万次的网站, 该项是免费的 对于低成本的网站, 假设一个月的产生的公网流量为 1GB, 0.8元 NAS, US$0.06/GB/Month, 网站大小为 50M, 即使按 1G 计算, 0.42元 RDS mysql 最基本的单机版本, 25元/月 函数计算计费 | NAS 定价 如上所述, 在低成本网站领域, 函数计算具有十分明显的成本优势,同时还保持了弹性能力,以后业务规模做大以后并没有技术切换成本(可能需要做的只是更换一个更强的关系型数据库), 同时财务成本增长配合预付费也能保持平滑。低成本网站变成高可用高性能网站如丝般顺滑, 高性能网站详情可以参考文末 FAQ 中的 Q1 问题。 函数计算运行 PHP 框架原理 在具体操作部署之前, 先简单梳理一遍函数计算运行 PHP 框架原理 2.1 传统服务器 PHP 运行原理 原理示意图image.png A simple nginx confimage.png 从上面原理示意图我们可以看出,Web 服务器根据 conf 中 location将 PHP 脚本交给 php-fpm 去解析,然后将解析后的结果返回给 client 端 2.2 FC 驱动 PHP 工程原理 image 函数计算的执行环境实例相当于传统 web 服务的 Apache/Nginx 用户函数相当于实现 Apache/Nginx 的 conf 中 location 用户将 Web 网站部署在 NAS,然后挂载 NAS 到函数的执行环境, 比如下面代码中 /mnt/auto 目录 对于 WordPress 入口函数代码就是这么简单: index.php 其中函数计算为用户提供了一个 $GLOBALS['fcPhpCgiProxy'] 对象用来和 php-fpm 进行交互,对PHP 工程中的 php 文件进行解析,该对象提供了两个重要的接口: requestPhpCgi requestPhpCgi($request, $docRoot, $phpFile = "index.php", $fastCgiParams = [], $options = []) $request: 跟 php http invoke 入口的参数一致 $docRoot: Web 工程的根目录 $phpFile: 用于拼接 cgi 参数中的 SCRIPT_FILENAME 的默认参数 $fastCgiParams: 函数计算内部尽量根据 $request给您构造 default cgi params, 但是如果您不是想要的,可以使用$fastCgiParams覆盖一些参数 (reference: cgi) $options: array类型,可选参数, debug_show_cgi_params 设为 true ,会打印每次请求 php 解析时候的 cgi 参数, 默认为 false ;readWriteTimeout 设置解析的时间, 默认为 5 秒 如果您有兴趣, 可以了解下函数计算 PHP Runtime: PHP 入口函数 PHP 执行环境 案例操作步骤 准备条件 免费开通函数计算, 按量付费,函数计算有很大的免费额度。 免费开通文件存储服务NAS, 按量付费 有一个域名, 比如 abc.com, 并将域名 CNAME 解析到函数计算(FC) 对应的 region 如您想在杭州的 region 部署 wordpres 网站, 则将 abc.com CNAME 解析到 12345.cn-hangzhou.fc.aliyuncs.com, 其中 12345 是您的 accountId 3.1 安装最新的 Fun 工具 安装版本为8.x 最新版或者10.x 、12.x nodejs 安装 funcraf 3.2 Clone 工程 git clone https://github.com/awesome-fc/fc-wordpress.git 3.3 根据需要使用的数据库进入不同的目录 复制 .env_example 文件为 .env, 并且修改 .env 中的信息为自己的信息 如果使用 mysql 数据库, 参考章节 3.3.1 如果使用 sqlite3 数据库, 参考章节 3.3.2 3.3.1 使用 mysql 数据库 进入目录 fc-wp-mysql fun nas init fun nas info fun nas init: 初始化 NAS, 基于您的 .env 中的信息获取(已有满足条件的nas)或创建一个同region可用的nas 如果你没有修改 templata.yml 中的配置 service名字, 那么则可以进入下一步; 如果有修改, 会在当前目录生成新的目录 .fun/nas/auto-default/{serviceName} (fun nas info 可以列出新的目录), 将默认目录下的 .fun/nas/auto-default/fc-wp-mysql/wordpress 的wordpress目录拷贝到 .fun/nas/auto-default/{serviceName} 下, 同时可以删除目录 .fun/nas/auto-default/fc-wp-mysql/wordpress 上传 wordpress 网站到 NAS fun nas sync fun nas ls nas:///mnt/auto/ fun nas sync: 将本地 NAS 中的内容(.fun/nas/auto-default/fc-wp-mysql)上传到 NAS 中的 fc-wp-mysql 目录 fun nas ls nas:///mnt/auto/: 查看我们是否已经正确将文件上传到了 NAS 3.3.2 使用 sqlite3 数据库 进入目录 fc-wp-sqlite fun nas init fun nas info fun nas init: 初始化 NAS, 基于您的 .env 中的信息获取(已有满足条件的nas)或创建一个同region可用的nas 如果你没有修改 templata.yml 中的配置 service名字, 那么则可以进入下一步; 如果有修改, 会在当前目录生成新的目录 .fun/nas/auto-default/{serviceName} (fun nas info 可以列出新的目录), 将默认目录下的 .fun/nas/auto-default/fc-wp-sqlite/wordpress 的wordpress目录拷贝到 .fun/nas/auto-default/{serviceName} 下, 同时可以删除目录 .fun/nas/auto-default/fc-wp-sqlite/wordpress 本地完成安装过程, 初始化 sqlite3 数据库 在目录 .fun/nas/auto-default/fc-wp-sqlite/wordpress 中输入命令: php -S 0.0.0.0:80 修改 host 文件,添加 127.0.0.1 hz.mofangdegisn.cn linux/mac : vim /etc/hosts windows7: C:\Windows\System32\drivers\etc 其中 hz.mofangdegisn.cn 是您预先准备的域名 通过浏览器输入 hz.mofangdegisn.cn, 这个时候没有mysql数据库设置页面,完成 wordpress 安装过程 成功安装以后, 这个时候, .fun/nas/auto-default/fc-wp-sqlite/wordpress/wp-content 下面应该有一个 database 的目录, ls -a 查看, 应该有 .ht.sqlite 这个 sqlite3 数据库文件 回退 host 文件的修改 注: 中间修改 host 的目的是初始化 sqlite3 数据库的时候, base site url 是提前准备的域名, 而不是 127.0.0.1 上传 wordpress 网站到 NAS fun nas sync fun nas ls nas:///mnt/auto/ fun nas sync: 将本地 NAS 中的内容(.fun/nas/auto-default/fc-wp-sqlite)上传到 NAS 中的 fc-wp-sqlite 目录 fun nas ls nas:///mnt/auto/: 查看我们是否已经正确将文件上传到了 NAS 3.4 部署函数到FC平台 接下来将函数部署到云平台: 修改 index.php 中的 $host 中的值 修改 template.yml LogConfig 中的 Project, 任意取一个不会重复的名字即可 修改 template.yml 自定义域名为自己提前准备好的域名 执行 fun deploy 登录控制台 https://fc.console.aliyun.com,可以看到service 和函数已经创建成功, 并且 service 也已经正确配置。 通过浏览器打开自己之前配置的域名, 比如本例中的 hz.mofangdegisn.cn mysql 版本数据库, 可以直接跟传统的 wordpress 一样,直接进入安装过程 sqlite3 版本数据库, 由于之前已经完成初始化,可以直接进入网站首页或网站后台 FAQ Q1: 函数计算能开发高性能高可用网站吗? A: 可以, 使用函数计算的单实例多并发功能和高性能数据库 单实例多并发 选择高性能关系型数据库,比如高可用的云数据库PolarDB 有必要再加上这些优化: 预留实例消除冷启动 + 预付费优化成本 极速型 NAS OSS 对象存储 + CDN 来存储和分发静态资源 目前 PHP Runtime 并不支持单实例多并发, 使用 Custom Runtime,可以将基于传统模式 nginx + php-fpm + mysql 开发的网站直接简单无缝迁移到函数计算平台,示例工程 customruntime-php 使用OSS对Wordpress进行图片动静分离 Q2: 使用低成本 sqlite3 版本的网站, 冷启动第一次打开很慢怎么办? A: 用一个 timer trigger 的函数 keep warm Q3: 使用低成本 sqlite3 版本的网站, 能支持多大的qps? A: 由 sqlite3 数据库性能决定, 这边有一些压测结果: image image 每次压力增大时候, 都有些冷启动,时间慢点,但是支持从压测结果来看支持 50 QPS 是没有疑问的, 是足够支持一些中小网站的。 Q4: 使用其他语言基于函数计算开发 serverless 网站可以吗? A: 可以, 比如 python: https://yq.aliyun.com/articles/603249 , 或者直接使用 custom runtime, 内置了 java、python 和 node, Custom Runtime 用户手册 , Custom Runtime 使用集锦

1934890530796658 2020-03-27 17:54:50 0 浏览量 回答数 0

回答

X-Engine是阿里云数据库产品事业部自研的联机事务处理OLTP(On-Line Transaction Processing)数据库存储引擎。作为自研数据库POLARDB的存储引擎之一,已经广泛应用在阿里集团内部诸多业务系统中,包括交易历史库、钉钉历史库等核心应用,大幅缩减了业务成本,同时也作为双十一大促的关键数据库技术,挺过了数百倍平时流量的冲击。 为什么设计一个新的存储引擎 X-Engine的诞生是为了应对阿里内部业务的挑战,早在2010年,阿里内部就大规模部署了MySQL数据库,但是业务量的逐年爆炸式增长,数据库面临着极大的挑战: 极高的并发事务处理能力(尤其是双十一的流量突发式暴增)。 超大规模的数据存储。 这两个问题虽然可以通过扩展数据库节点的分布式方案解决,但是堆机器不是一个高效的手段,我们更想用技术的手段将数据库性价比提升到极致,实现以少量资源换取性能大幅提高的目的。 传统数据库架构的性能已经被仔细的研究过,数据库领域的泰斗,图灵奖得主Michael Stonebreaker就此写过一篇论文 《OLTP Through the Looking Glass, and What We Found There》 ,指出传统关系型数据库,仅有不到10%的时间是在做真正有效的数据处理工作,剩下的时间都浪费在其它工作上,例如加锁等待、缓冲管理、日志同步等。 造成这种现象的原因是因为近年来我们所依赖的硬件体系发生了巨大的变化,例如多核(众核)CPU、新的处理器架构(Cache/NUMA)、各种异构计算设备(GPU/FPGA)等,而架构在这些硬件之上的数据库软件却没有太大的改变,例如使用B-Tree索引的固定大小的数据页(Page)、使用ARIES算法的事务处理与数据恢复机制、基于独立锁管理器的并发控制等,这些都是为了慢速磁盘而设计,很难发挥出现有硬件体系应有的性能。 基于以上原因,阿里开发了适合当前硬件体系的存储引擎,即X-Engine。 X-Engine架构 全新架构的X-Engine存储引擎不仅可以无缝对接兼容MySQL(得益于MySQL Pluginable Storage Engine特性),同时X-Engine使用分层存储架构。 因为目标是面向大规模的海量数据存储,提供高并发事务处理能力和降低存储成本,在大部分大数据量场景下,数据被访问的机会是不均等的,访问频繁的热数据实际上占比很少,X-Engine根据数据访问频度的不同将数据划分为多个层次,针对每个层次数据的访问特点,设计对应的存储结构,写入合适的存储设备。 X-Engine使用了LSM-Tree作为分层存储的架构基础,并进行了重新设计: 热数据层和数据更新使用内存存储,通过内存数据库技术(Lock-Free index structure/append only)提高事务处理的性能。 流水线事务处理机制,把事务处理的几个阶段并行起来,极大提升了吞吐。 访问频度低的数据逐渐淘汰或是合并到持久化的存储层次中,并结合多层次的存储设备(NVM/SSD/HDD)进行存储。 对性能影响比较大的Compaction过程做了大量优化: 拆分数据存储粒度,利用数据更新热点较为集中的特征,尽可能的在合并过程中复用数据。 精细化控制LSM的形状,减少I/O和计算代价,有效缓解了合并过程中的空间增大。 同时使用更细粒度的访问控制和缓存机制,优化读的性能。 技术特点 利用FPGA硬件加速Compaction过程,使得系统上限进一步提升。这个技术属首次将硬件加速技术应用到在线事务处理数据库存储引擎中,相关论文 《FPGA-Accelerated Compactions for LSM-based Key Value Store》 已经被2020年的顶级会议FAST'20接收。 通过数据复用技术减少数据合并代价,同时减少缓存淘汰带来的性能抖动。 使用多事务处理队列和流水线处理技术,减少线程上下文切换代价,并计算每个阶段任务量配比,使整个流水线充分流转,极大提升事务处理性能。相对于其他类似架构的存储引擎(例如RocksDB),X-Engine的事务处理性能有10倍以上提升。 X-Engine使用的Copy-on-write技术,避免原地更新数据页,从而对只读数据页面进行编码压缩,相对于传统存储引擎(例如InnoDB),使用X-Engine可以将存储空间降低至10%~50%。 Bloom Filter快速判定数据是否存在,Surf Filter判断范围数据是否存在,Row Cache缓存热点行,加速读取性能。 LSM基本逻辑 LSM的本质是所有写入操作直接以追加的方式写入内存。每次写到一定程度,即冻结为一层(Level),并写入持久化存储。所有写入的行,都以主键(Key)排序好后存放,无论是在内存中,还是持久化存储中。在内存中即为一个排序的内存数据结构(Skiplist、B-Tree、etc),在持久化存储也作为一个只读的全排序持久化存储结构。 普通的存储系统若要支持事务处理,需要加入一个时间维度,为每个事务构造出一个不受并发干扰的独立视域。例如存储引擎会对每个事务定序并赋予一个全局单调递增的事务版本号(SN),每个事务中的记录会存储这个SN以判断独立事务之间的可见性,从而实现事务的隔离机制。 如果LSM存储结构持续写入,不做其他的动作,那么最终会成为如下结构。 这种结构对于写入是非常友好的,只要追加到最新的内存表中即完成,为实现故障恢复,只需记录Redo Log,因为新数据不会覆盖旧版本,追加记录会形成天然的多版本结构。 但是如此累积,冻结的持久化层次越来越多,会对查询会产生不利的影响。例如对同一个key,不同事务提交产生的多版本记录会散落在各个层次中;不同的key也会散落在不同层次中。读操作需要查找各个层并合并才能得到最终结果。 因此LSM引入了Compaction操作解决这个问题,Compaction操作有2种作用: 控制LSM层次形状 一般的LSM形状都是层次越低,数据量越大(倍数关系),目的是为了提升读性能。 通常存储系统的数据访问都有局部性,大量的访问都集中在少部分数据上,这也是缓存系统能有效工作的基本前提。在LSM存储结构中,如果把访问频率高的数据尽可能放在较高的层次上,存放在快速存储设备中(例如NVM、DRAM),而把访问频率低的数据放在较低层次中,存放在廉价慢速存储设备中。这就是X-Engine的冷热分层概念。 合并数据 Compaction操作不断的把相邻层次的数据合并,并写入更低层次。合并的过程实际上是把要合并的相邻两层或多层的数据读出来,按key排序,相同的key如果有多个版本,只保留新的版本(比当前正在执行的活跃事务中最小版本号新),丢掉旧版本数据,然后写入新的层,这个操作非常耗费资源。 合并数据除了考虑冷热分层以外,还需要考虑其他维度,例如数据的更新频率,大量的多版本数据在查询的时候会浪费更多的I/O和CPU,因此需要优先进行合并以减少记录的版本数量。X-Engine综合考虑了各种策略形成自己的Compaction调度机制。 高度优化的LSM X-Engine的memory tables使用了无锁跳表(Locked-free SkipList),并发读写的性能较高。在持久化层如何实现高效,就需要讨论每层的细微结构。 数据组织 X-Engine的每层都划分成固定大小的Extent,存放每个层次中的数据的一个连续片段(Key Range)。为了快速定位Extent,为每层Extents建立了一套索引(Meta Index),所有这些索引,加上所有的memory tables(active/immutable)一起组成了一个元数据树(Metadata Tree),root节点为Metadata Snapshot,这个树结构类似于B-Tree。 X-Engine中除了当前的正在写入的active memory tables以外,其他结构都是只读的,不会被修改。给定某个时间点,例如LSN=1000,上图中的Metadata Snapshot 1引用到的结构即包含了LSN=1000时的所有的数据的快照,因此这个结构被称为Snapshot。 即便是Metadata结构本身,也是一旦生成就不会被修改。所有的读请求都是以Snapshot为入口,这是X-Engine实现Snapshot级别隔离的基础。前文说过随着数据写入,累积数据越多,会执行Compaction操作、冻结memory tables等,这些操作都是用Copy-on-write实现,即每次都将修改产生的结果写入新的Extent,然后生成新的Meta Index结构,最终生成新的Metadata Snapshot。 例如执行一次Compaction操作会生成新的Metadata Snapshot,如下图所示。 可以看到Metadata Snapshot 2相对于Metadata Snapshot 1并没有太多的变化,仅仅修改了发生变更的一些叶子节点和索引节点。 事务处理 得益于LSM的轻量化写机制,写入操作固然是其明显的优势,但是事务处理不只是把更新的数据写入系统那么简单,还要保证ACID(原子性、一致性、隔离性、持久性),涉及到一整套复杂的流程。X-Engine将整个事务处理过程分为两个阶段: 读写阶段 校验事务的冲突(写写冲突、读写冲突),判断事务是否可以执行、回滚重试或者等锁。如果事务冲突校验通过,则把修改的所有数据写入Transaction Buffer。 提交阶段 写WAL、写内存表,以及提交并返回用户结果,这里面既有I/O操作(写日志、返回消息),也有CPU操作(拷贝日志、写内存表)。 为了提高事务处理吞吐,系统内会有大量事务并发执行,单个I/O操作比较昂贵,大部分存储引擎会倾向于聚集一批事务一起提交,称为Group Commit,能够合并I/O操作。但是一组事务提交的过程中,还是有大量等待过程的,例如写入日志到磁盘过程中,除了等待落盘无所事事。 X-Engine为了进一步提升事务处理的吞吐,使用流水线技术,把提交阶段分为4个独立的更精细的阶段: 拷贝日志到缓冲区(Log Buffer) 日志落盘(Log Flush) 写内存表(Write memory table) 提交返回(Commit) 事务到了提交阶段,可以自由选择执行流水线中任意一个阶段,只要流水线任务的大小划分得当,就能充分并行起来,流水线处于接近满载状态。另外这里利用的是事务处理的线程,而非后台线程,每个线程在执行的时候,选择流水线中的一个阶段执行任务,或者空闲后处理其他请求,没有等待,也无需切换,充分利用了每个线程的能力。 读操作 LSM处理多版本数据的方式是新版本数据记录会追加在老版本数据后面,从物理上看,一条记录不同的版本可能存放在不同的层,在查询的时候需要找到合适的版本(根据事务隔离级别定义的可见性规则),一般查询都是查找最新的数据,总是由最高的层次往低层次找。 对于单条记录的查找而言,一旦找到便可以终止,如果记录在比较高的层次,例如memory tables,很快便可以返回;如果记录已经落入了很低的层次,那就得逐层查找,也许Bloom Filter可以跳过某些层次加快这个旅程,但毕竟还是有很多的I/O操作。X-Engine针对单记录查询引入了Row Cache,在所有持久化的层次的数据之上做了一个缓存,在memory tables中没有命中的单行查询,在Row Cache之中也会被捕获。Row Cache需要保证缓存了所有持久化层次中最新版本的记录,而这个记录是可能发生变化的,例如每次flush将只读的memory tables写入持久化层次时,就需要恰当的更新Row Cache中的缓存记录,这个操作比较微妙,需要精心的设计。 对于范围扫描而言,因为没法确定一个范围的key在哪个层次中有数据,只能扫描所有的层次做合并之后才能返回最终的结果。X-Engine采用了一系列的手段,例如SuRF(SIGMOD'18 best paper)提供range scan filter减少扫描层数、异步I/O与预取。 读操作中最核心的是缓存设计,Row Cache负责单行查询,Block Cache负责Row Cache的漏网之鱼,也用来进行范围扫描。由于LSM的Compaction操作会一次更新大量的Data Block,导致Block Cache中大量数据短时间内失效,导致性能的急剧抖动,因此X-Engine做了很多的优化: 减少Compaction的粒度。 减少Compaction过程中改动的数据。 Compaction过程中针对已有的缓存数据做定点更新。 Compaction Compaction操作是比较重要的,需要把相邻层次交叉的Key Range数据读取合并,然后写到新的位置。这是为前面简单的写入操作付出的代价。X-Engine为优化这个操作重新设计了存储结构。 如前文所述,X-Engine将每一层的数据划分为固定大小的Extent,一个Extent相当于一个小而完整的排序字符串表(SSTable),存储了一个层次中的一个连续片段,连续片段又进一步划分为一个个连续的更小的片段Data Block,相当于传统数据库中的Page,只不过Data Block是只读而且不定长的。 回看并对比Metadata Snapshot 1和Metadata Snapshot 2,可以发现Extent的设计意图。每次修改只需要修改少部分有交叠的数据,以及涉及到的Meta Index节点。两个Metadata Snapshot结构实际上共用了大量的数据结构,这被称为数据复用技术(Data Reuse),而Extent大小正是影响数据复用率的关键,Extent作为一个完整的被复用的物理结构,需要尽可能的小,这样与其他Extent数据交叉点会变少,但又不能非常小,否则需要索引过多,管理成本太大。 X-Engine中Compaction的数据复用是非常彻底的,假设选取两个相邻层次(Level1, Level2)中的交叉的Key Range所涵盖的Extents进行合并,合并算法会逐行进行扫描,只要发现任意的物理结构(包括Data Block和Extent)与其他层中的数据没有交叠,则可以进行复用。只不过Extent的复用可以修改Meta Index,而Data Block的复用只能拷贝,即便如此也可以节省大量的CPU。 一个典型的数据复用在Compaction中的过程可以参考下图。 可以看出数据复用的过程是在逐行迭代的过程中完成的,不过这种精细的数据复用带来另一个副作用,即数据的碎片化,所以在实际操作的过程中也需要根据实际情况进行分析。 数据复用不仅给Compaction操作本身带来好处,降低操作过程中的I/O与CPU消耗,更对系统的综合性能产生一系列的影响。例如c、Compaction过程中数据不用完全重写,大大降低了写入时空间的增大;大部分数据保持原样,数据缓存不会因为数据更新而失效,减少合并过程中因缓存失效带来的读性能抖动。 实际上,优化Compaction的过程只是X-Engine工作的一部分,更重要的是优化Compaction调度的策略,选什么样的Extent、定义compaction任务的粒度、执行的优先级等,都会对整个系统性能产生影响,可惜并不存在什么完美的策略,X-Engine积累了一些经验,定义了很多规则,而探索更合理的调度策略是未来一个重要方向。 适用场景 请参见X-Engine最佳实践。 如何使用X-Engine 请参见使用X-Engine引擎。 后续发展 作为MySQL的存储引擎,持续地提升MySQL系统的兼容能力是一个重要目标,后续会根据需求的迫切程度逐步加强原本取消的一些功能,例如外键,以及对一些数据结构、索引类型的支持。 X-Engine作为存储引擎,核心的价值还在于性价比,持续提升性能降低成本,是一个长期的根本目标,X-Engine还在Compaction调度、缓存管理与优化、数据压缩、事务处理等方向上进行深层次的探索。 X-Engine不仅仅局限为一个单机的数据库存储引擎,未来还将作为自研分布式数据库POLARDB分布式版本的核心,提供企业级数据库服务。

游客yl2rjx5yxwcam 2020-03-08 13:24:40 0 浏览量 回答数 0
阿里云大学 云服务器ECS com域名 网站域名whois查询 开发者平台 小程序定制 小程序开发 国内短信套餐包 开发者技术与产品 云数据库 图像识别 开发者问答 阿里云建站 阿里云备案 云市场 万网 阿里云帮助文档 免费套餐 开发者工具 SQL审核 小程序开发制作 视频内容分析 企业网站制作 视频集锦 代理记账服务 2020阿里巴巴研发效能峰会 企业建站模板 云效成长地图 高端建站 人工智能 阿里云云栖号 云栖号案例 云栖号直播