• 关于

    读写系统怎么重启

    的搜索结果

回答

引用楼主爱创斯博于2014-04-16 21:06发表的 看看怎么回事呢! : 反复重置磁盘更换系统会降低服务器的性能IO?感觉比以前慢了很多.重启和停止都需要花很长时间.注:在没有装任何东西出现的情况.配置一样.但系统运行.不知道怎么回事.慢.慢.! 楼主重启和停止慢的时候,楼主可以使用控制台的ecs连接管理终端vnc功能到界面看下启动和停止过程是否有异常, 反复重置磁盘更换系统磁盘慢楼主可以测试下磁盘io读写性能,看下数据。

qilu 2019-12-02 03:05:35 0 浏览量 回答数 0

问题

阿里云的oracle故障解决案例

oracledbawyq 2019-12-01 21:12:54 15556 浏览量 回答数 2

回答

Re搬到阿里云半年,平均每天宕机一次,求解决 最好是能给网站一些建议,是需要提升配置,还是怎么,如果通过提升配置能解决问题,也可以。这样经常宕机谁受得了! ------------------------- Re搬到阿里云半年,平均每天宕机一次,求解决 阿里云工程师的解答: 您好,经查您的主机经查会有io读写很高,和带宽跑满的现象,见截图,应该是您主机内部应用导致的,请您登陆主机内部核查一下。 感谢您的支持。 今早上9点宕机一次;这是今晚6点多刚才宕机的后台监控截图,CPU占用50%不到;磁盘读写早上9点宕机的时候比较高,晚上6点宕机的时候也不算很高;5M的带宽肯定没用满。 又宕机了,烦啊! ------------------------- Re搬到阿里云半年,平均每天宕机一次,求解决 唉,早晚得重启一次。 ------------------------- Re搬到阿里云半年,平均每天宕机一次,求解决 今天上午11点10分又宕机了,截个图,大家帮我看看。 昨天将网站首页较大的图片禁止掉,有所好转,今天上午还是宕机了。我买的是标准A型的,2核处理器、1.5G内存、5M带宽,服务器流量确实不是很大,上面两个区县级的小论坛,每天IP只有3000个。 ------------------------- Re搬到阿里云半年,平均每天宕机一次,求解决 引用第16楼ap9211a0k于2012-12-18 10:51发表的  : 看linux中top中wa比例 如果这个比例高的花,应该是磁盘io。 可以修改网站对图片到客户端的缓存时间,以及程序对磁盘的读写,来解决 建议使用nginx代替apache,因为nginx的静态效果比apache好很多,直接命令安装就可以了。 如果你用的是windows,我上面的就当白说了,呵呵 我用的就是nginx ------------------------- ReRe搬到阿里云半年,平均每天宕机一次,求解决 引用第15楼rat_cocu于2012-12-18 10:01发表的 Re搬到阿里云半年,平均每天宕机一次,求解决 : 是不是环境设置的问题呢?希望阿里出一个比较稳定傻瓜化的环境配置系统,这样也可以大大减轻售后的压力啊! 是啊,大部分站长以前都是VPS,我虽然也在学习linux,不过一下子上手也没那么快。特别是服务器优化方面很多站长都不是很熟悉。 ------------------------- ReRe搬到阿里云半年,平均每天宕机一次,求解决 引用第14楼ouotuo于2012-12-18 09:42发表的 Re搬到阿里云半年,平均每天宕机一次,求解决 : 以前我有一台机器也卡死呢。。。后来技术人员帮我移一下机器就没事了。你叫他帮你移一下呢。 移机器麻烦吗? ------------------------- Re搬到阿里云半年,平均每天宕机一次,求解决 可以ping通 ------------------------- Re搬到阿里云半年,平均每天宕机一次,求解决 disucz本身都是伪静态,唉,基本是一天重启两次。 ------------------------- Re搬到阿里云半年,平均每天宕机一次,求解决 我宕机的问题终于解决了。主要原因还是我两个网站的数据库大了,直接在云服务器上建数据库不知道是磁盘IO的问题还是最大连接数做了限制,导致频繁宕机。后来买了个最低端的关系型数据库RDS,问题得到解决。 另外日志文件和数据库文件太多也会导致云主机速度慢,要经常清理日志文件。 希望遇到类似情况的XD少走弯路,网站数据库大于500M的还是弄个RDS保险。

plcsq 2019-12-02 00:18:49 0 浏览量 回答数 0

阿里云试用中心,为您提供0门槛上云实践机会!

0元试用32+款产品,最高免费12个月!拨打95187-1,咨询专业上云建议!

问题

数据库百问,教你快速上手数据库

yq传送门 2019-12-01 20:16:46 31116 浏览量 回答数 21

问题

巧用linux云服务器下的的/dev/shm/,避开磁盘IO不给力!

qilu 2019-12-01 21:17:10 58773 浏览量 回答数 53

回答

按量付费计费规则说明一、“按量付费”介绍 阿里云全新推出的付费模式,按实际使用量后付费开通,可随时开启随时释放。 按需取用,按需付费,无需购买大量设备,相比于传统主机投入成本降低30%-80%;支持多种主流操作系统,让您以服务的方式使用计算及存储资源。 目前阿里云云服务器有两种付费模式:包年包月、按量付费。 二、“按量付费“计费说明 1、云服务器按量付费收费方式 1.1 采用阿里云账户先充值,后按实际用量结算方式进行结算。以小时为单位,按实际消费金额对账户余额进行扣费。 1.2 “按量付费”云服务器计费项包括:CPU、内存、数据盘、公网带宽(按固定带宽、按使用流量两种可选)。 2、开通说明 2.1 开通按量付费的云服务器,现金账户余额不得少于100.00元,如账户金额少于100.00元,需充值后方可开通。 3、计费说明 3.1 每小时计费总费用=CPU费用+内存费用+数据盘费用+公网带宽费用。 3.2 CPU、内存、数据盘:按固定费用每小时扣费; 3.3 公网带宽:固定带宽,按固定费用每小时扣费; 3.4 公网带宽:按使用流量,仅单向收取流出流量费用(0.8 元/GB),流入流量免费,按实际使用金额每小时扣费。例如您在1小时内公网流出流量为2.5GB,收取费用为2.5GB*0.8元/小时=2.0元。 4、结算说明 4.1 结算周期。以小时为单位整点结算(均以北京时间为准)。 开通时间建议: 整点开通才划算,非整点开通,按整点算钱!提前释放按整点周期算钱! 比如:您在1点20分开通,那么时间到2点的时候就算做1小时。所以尽量在整点后几分钟内开通,在整点前几分钟释放。 4.2 结算范围 实际开通时长(即云服务器从“开通”开启计费到“释放“结束计费,以小时为单位整点结算)因账户欠费而产生的账单,账户一旦充值系统将会自动结算。 若账号下有欠费账单,可能会导致无法结算其他订单或结算其他订单时系统会自动优先扣除欠费账单金额。 4.3 结算时间 以系统自动结算时间为准 。 温馨提醒:避免超出预期开通时长,请设置自动释放服务时间!(可进入”用户中心“-”控制台“设置) 。 5、释放规则 5.1 按小时扣费后,“阿里云现金账户”出现欠费。 即在整点扣费时,(现金账户余额-账单中当周期整点结算的费用)<0时,按量付费的ECS将会欠费停机,从停机时刻起数据保留7天(即168小时,自行设置释放的除外),7天后实例以及实例相关数据(包括临时磁盘,云磁盘、随ECS实例释放的独立云磁盘,快照)均处于不可用状态,系统会回收相关欠费资源,数据无法找回。 欠费后,按量付费的云磁盘会被限制使用,无法实现正常的IO读写访问,会影响挂载该欠费磁盘的ECS实例正常运行,包括但不限于,应用程度读写性能低下,部分操作提示严重超时,某些操作系统版本下关机或重启失败等情况。 5.2 已设置自动释放时间的云服务器,会按照设置时间系统自动释放(按量付费服务器实例可能存在释放延迟,如果您设置释放时间点由于释放延迟进入下一计费周期,不会收取下一计费周期费用,只会针对您设置的释放时间点前的时间进行计费) 若按小时扣费后,“阿里云现金账户”余额为0元,”按量付费“的云服务器不遵循设置的系统释放时间,自账号为0元时起7天后实例以及实例相关数据(包括临时磁盘,云磁盘、随ECS实例释放的独立云磁盘,快照)都将被永久删除,数据无法找回。 5.3 提醒规则 余额不足提醒:以小时为单位整点结算后,若下一计费周期内账户可用余额小于上一周期账单金额,则发短信和邮件提醒; 释放通知:因到期/欠费释放,系统会短信和邮件通知。 6、举例 6.1 1:00整开通云服务器,1:00~2:00为第一个结算周期,实际开通时长60分钟算作1小时计费结算。 6.2 1:59分开通云服务器,1:00~2:00为第一个结算周期,实际开通时长1分钟算作1小时计费结算;2:01分释放云服务器,2:00~3:00为第二个结算周期,实际开通时长1分钟算作1小时计费结算,此用户需要支付2小时费用。 说明:此“ 释放 ”包括用户通过控制台自行操作释放、以小时为单位整点结算后现金账户欠费由系统触发的释放。请设置”自动释放服务时间“避免系统触发的释放导致超出预期的开通时长。 三、按量付费开通须知 1、”按量付费“均暂不支持更换配置 1.1 暂不支持配置变更功能(包括带宽升级、CPU和内存升级)。 若选择0M固定带宽:不分配外网IP,不支持0M带宽升级,请谨慎选择。 2、计费模式不支持更换 2.1 “包年包月“和”按量付费“不支持相互更换:1台云服务器只能选择1种,无法同时选择; 2.2 公网带宽:按固定带宽/按使用流量计费模式不支持相互更换,1台云服务器只能选择1种,无法同时选择。 3、金牌服务不支持 3.1 不提供备案服务。如果您的网站需要备案,请您包年包月购买,价更优! 3.2 不支持5天无理由退款 3.3 不支持免费数据迁移 4、代金券使用限制 仅支持有效期内通用券。 5、免费使用云盾、云监控、负载均衡 “按量付费”和“包年包月”仅计费模式不同,可同样免费使用云盾、云监控、负载均衡等阿里云产品。 四、常见问题 FAQ Q:按量付费我不能购买是什么原因? A: 请检查您是否已经通过实名认证,如果没有实名认证,建议您前往用户中心做实名认证。 目前按量付费是每个账号50台购买限制,如果您有超过50台的需求,可以根据提交工单申请按量高配。 由于管控限制,当某个地域售卖量达到限制的时候该地域会暂时关闭,建议您稍后再来尝试购买 Q:“固定带宽”和带宽“按使用流量”有什么区别? A: 固定带宽:买多少是多少; 带宽按使用流量:评估使用峰值,对带宽进行选择,按使用流量扣费。 Q:公网带宽“按使用流量”我应该选多少M才合适? A: 根据应用及实际使用情况进行选择。 Q:没有通过支付宝实名认证就不能购买“按量付费”云服务器吗? A: 是的,下单购买前,必须进行实名认证。Q:“按量付费”代金券能用吗? A:目前代金券账户仅限有效期内的通用券可用,请及时关注代金券的有效期 。 Q:如果金额不足,会提示么?什么时候提示?云服务器会直接停掉么? A:扣费后,若阿里云现金账户(代金券账户仅限有效期内的通用券可用)余额为0元,云服务器上的数据会保留7天后自动释放!详情查看《按量付费云服务器开通释放规则》 提醒规则: 余额不足提醒:每小时整点结算后仍有未释放的云服务器,若下一计费周期内账户可用余额小于上一周期账单金额,则发短信和邮件提醒;释放通知:因到期/欠费释放,系统会短信和邮件通知。 Q:账户余额不足,服务器数据会受影响吗? A:按小时扣费后,当“阿里云账户”出现欠费,即现金账户(代金券账户仅限有效期内的通用券可用)余额”为0元,“按量付费”的云服务器将不可用,如7天内没有续费,服务器将自动释放,数据不可恢复。 Q:一次性可以购买多少台云服务器?一个云帐号可以买几台云服务器? A:一次性最多可购买50台云服务器,一个云帐号下最多可以购买50台(包含50台)。 Q:结算时间怎么算?例如我1点30分钟开通,到2点,算半小时还是一小时? A:整点结算,以系统自动结算时间为准。算1小时。建议整点开通。 Q: 云服务器的地域是怎么选择的? A:地域可以自行选择。 Q:如果设置了带宽峰值,后期可以再进行调整吗? A:带宽峰值设置之后,就无法进行调整。 Q:我的服务器被攻击了,流量给我计费了?跟我自己检测流量差距很大,是什么原因? A:流量计费仅对出网带宽进行收费,网络攻击如属于入网带宽,则不会进行计费,如产生了出网带宽,会进行计费。推荐使用云盾进行攻击防护。 Q:能否自行关闭服务器? A:可以自行设置自动释放服务时间。 Q:“按量付费”,发票怎么开? A:可以开发票,申请发票时将基于月结算单开具发票,月结算单不可拆分开票,请您登录阿里云用户中心进行申请发票 。 Q:“按量付费”,能备案吗? A: 不提供备案服务,如果您的网站需要备案,请您包年包月购买,价更优! Q:能否支持5天内无理由退款? A:不支持 Q:是否支持百倍赔偿? A:支持。 Q:“按量计费”的云服务器(ECS)停机和关机后,还会产生费用吗? A:停机不产生费用,而关机将按正常计费规则收取费用。关机状态的按量付费ECS因服务时间到期或欠费时,将会变为“停机”状态。“停机”是指按量付费ECS到期或因欠费而自动停止服务的状态;而“关机”是指按量付费ECS在正常运行期间(账号余额>0元),用户在管理控制台中点击“停止”后,服务器即进入关机状态。 说明:按量付费的ECS停机后,数据保留7天后会自动释放;如需快速释放,您也可以登录ECS控制台->管理->释放,届时您ECS上的数据将立即被全部清除。 Q:“按量付费”的云服务器对内、对外产生的流量怎么收费的? A:同一局域网内的云服务器之间交互产生的流量全部免费,云服务器与公网交互产生的流量说明如下: 带宽按使用流量计费:互联网流入云服务器的流量是免费的,例如您通过云服务器从互联网上下载文件,阿里云不会收取任何费用,只有云服务器向互联网流出的流量才会产生费用。按固定带宽计费:在以单位价格购买的固定带宽上限之内,云服务器向互联网流出的流量都不会再另收取任何费用。

元芳啊 2019-12-01 23:23:10 0 浏览量 回答数 0

问题

dubbo 的工作原理?注册中心挂了的问题?说说一次 rpc 请求的流程?【Java问答】47期

剑曼红尘 2020-06-30 09:02:47 8 浏览量 回答数 1

问题

【archsummit 回顾】阿里云章文嵩:构建大型云计算平台分布式技术的实践

云课堂 2019-12-01 21:03:36 14448 浏览量 回答数 9

问题

程序员报错行为大赏-配置报错

问问小秘 2020-06-11 13:18:25 6 浏览量 回答数 1

回答

MongoDB ACID事务支持 这里要有一定的关系型数据库的事务的概念,不然不一定能理解的了这里说的事务概念。 下面说一说MongoDB的事务支持,这里可能会有疑惑,前面我们在介绍MongoDB时,说MongoDB是一个NoSQL数据库,不支持事务。这里又介绍MongoDB的事务。这里要说明一下MongoDB的事务支持跟关系型数据库的事务支持是两码事,如果你已经非常了解关系型数据库的事务,通过下面一副图对比MongoDB事务跟MySQL事务的不同之处。 MongoDB是如何实现事务的ACID? 1)MongoDB对原子性(Atomicity)的支持 原子性在Mongodb中到底是一个什么概念呢?为什么说支持但又说Mongodb的原子性是单行/文档级原子性,这里提供了一个MongoDB更新语句样例,如下图: MongoDB是如何实现事务的ACID? 更新“username”等于“tj.tang”的文档,更新salary、jobs、hours字段。这里对于这三个字段Mongodb在执行时要么都更新要么都不更新,这个概念在MySQL中可能你没有考虑过,但在MongoDB中由于文档可以嵌套子文档可以很复杂,所以Mongodb的原子性叫单行/文档级原子性。 对于关系型数据库的多行、多文档、多语句原子性目前Mongodb是不支持的,如下情况: MongoDB是如何实现事务的ACID? MongoDB更新条件为工资小于50万的人都把工资调整为50万,这就会牵扯到多文档更新原子性。如果当更新到Frank这个文档时,出现宕机,服务器重启之后是无法像关系型数据库那样做到数据回滚的,也就是说处理这种多文档关系型数据库事务的支持,但MongoDB不支持。那么怎么解决Mongodb这个问题呢?可以通过建模,MongoDB不是范式而是反范式的设计,通过大表和小表可以把相关的数据放到同一个文档中去。然后通过一条语句来执行操作。 2)MongoDB对一致性(consistency)的支持 对于数据一致性来说,传统数据库(单机)跟分布式数据库(MongoDB)对于数据一致性是不太一样的,怎么理解呢?如下图: MongoDB是如何实现事务的ACID? 对于传统型数据库来说,数据一致性主要是在单机上,单机的问题主要是数据进来时的规则检验,数据不能被破坏掉。而在分布式数据库上,因为他们都是多节点分布式的,我们讲的一致性往往就是讲的各个节点之间的数据是否一致。而MongoDB在这点上做的还是不错的,MongoDB支持强一致性或最终一致性(弱一致性),MongoDB的数据一致性也叫可调一致性,什么意思呢?如下图: MongoDB是如何实现事务的ACID? MongoDB的可调一致性,也就是可以自由选择强一致性或最终一致性,如果你的应用场景是前台的方式可以选择强一致性,如果你的应用场景是后台的方式(如报表)可以选择弱一致性。 一致性 上面我们讲到了通过将数据冗余存储到不同的节点来保证数据安全和减轻负载,下面我们来看看这样做引发的一个问题:保证数据在多个节点间的一致性是非常困难的。在实际应用中我们会遇到很多困难,同步节点可能会故障,甚至会无法恢复,网络可能会有延迟或者丢包,网络原因导致集群中的机器被分隔成两个不能互通的子域等等。在NoSQL中,通常有两个层次的一致性:第一种是强一致性,既集群中的所有机器状态同步保持一致。第二种是最终一致性,既可以允许短暂的数据不一致,但数据最终会保持一致。我们先来讲一下,在分布式集群中,为什么最终一致性通常是更合理的选择,然后再来讨论两种一致性的具体实现结节。 关于CAP理论 为什么我们会考虑削弱数据的一致性呢?其实这背后有一个关于分布式系统的理论依据。这个理论最早被Eric Brewer提出,称为CAP理论,尔后Gilbert和Lynch对CAP进行了理论证明。这一理论首先把分布式系统中的三个特性进行了如下归纳: 一致性(C):在分布式系统中的所有数据备份,在同一时刻是否同样的值。 可用性(A):在集群中一部分节点故障后,集群整体是否还能响应客户端的读写请求。 分区容忍性(P):集群中的某些节点在无法联系后,集群整体是否还能继续进行服务。 而CAP理论就是说在分布式存储系统中,最多只能实现上面的两点。而由于当前的网络硬件肯定会出现延迟丢包等问题,所以分区容忍性是我们必须需要实现的。所以我们只能在一致性和可用性之间进行权衡,没有NoSQL系统能同时保证这三点。 要保证数据强一致性,最简单的方法是令写操作在所有数据节点上都执行成功才能返回成功,也就是同步概念。而这时如果某个结点出现故障,那么写操作就成功不了了,需要一直等到这个节点恢复。也就是说,如果要保证强一致性,那么就无法提供7×24的高可用性。 而要保证可用性的话,就意味着节点在响应请求时,不用完全考虑整个集群中的数据是否一致。只需要以自己当前的状态进行请求响应。由于并不保证写操作在所有节点都写成功,这可能会导致各个节点的数据状态不一致。 CAP理论导致了最终一致性和强一致性两种选择。当然,事实上还有其它的选择,比如在Yahoo的PNUTS中,采用的就是松散的一致性和弱可用性结合的方法。但是我们讨论的NoSQL系统没有类似的实现,所以我们在后续不会对其进行讨论。 强一致性 强一致性的保证,要求所有数据节点对同一个key值在同一时刻有同样的value值。虽然实际上可能某些节点存储的值是不一样的,但是作为一个整体,当客户端发起对某个key的数据请求时,整个集群对这个key对应的数据会达成一致。下面就举例说明这种一致性是如何实现的。 假设在我们的集群中,一个数据会被备份到N个结点。这N个节点中的某一个可能会扮演协调器的作用。它会保证每一个数据写操作会在成功同步到W个节点后才向客户端返回成功。而当客户端读取数据时,需要至少R个节点返回同样的数据才能返回读操作成功。而NWR之间必须要满足下面关系:R+W>N 下面举个实在的例子。比如我们设定N=3(数据会备份到A、B、C三个结点)。比如值 employee30:salary 当前的值是20000,我们想将其修改为30000。我们设定W=2,下面我们会对A、B、C三个节点发起写操作(employee30:salary, 30000),当A、B两个节点返回写成功后,协调器就会返回给客户端说写成功了。至于节点C,我们可以假设它从来没有收到这个写请求,他保存的依然是20000那个值。之后,当一个协调器执行一个对employee30:salary的读操作时,他还是会发三个请求给A、B、C三个节点: 如果设定R=1,那么当C节点先返回了20000这个值时,那我们客户端实际得到了一个错误的值。 如果设定R=2,则当协调器收到20000和30000两个值时,它会发现数据不太正确,并且会在收到第三个节点的30000的值后判断20000这个值是错误的。 所以如果要保证强一致性,在上面的应用场景中,我们需要设定R=2,W=2 如果写操作不能收到W个节点的成功返回,或者写操作不能得到R个一致的结果。那么协调器可能会在某个设定的过期时间之后向客户端返回操作失败,或者是等到系统慢慢调整到一致。这可能就导致系统暂时处于不可用状态。 对于R和W的不同设定,会导致系统在进行不同操作时需要不同数量的机器节点可用。比如你设定在所有备份节点上都写入才算写成功,既W=N,那么只要有一个备份节点故障,写操作就失败了。一般设定是R+W = N+1,这是保证强一致性的最小设定了。一些强一致性的系统设定W=N,R=1,这样就根本不用考虑各个节点数据可能不一致的情况了。 HBase是借助其底层的HDFS来实现其数据冗余备份的。HDFS采用的就是强一致性保证。在数据没有完全同步到N个节点前,写操作是不会返回成功的。也就是说它的W=N,而读操作只需要读到一个值即可,也就是说它R=1。为了不至于让写操作太慢,对多个节点的写操作是并发异步进行的。在直到所有的节点都收到了新的数据后,会自动执行一个swap操作将新数据写入。这个操作是原子性和一致性的。保证了数据在所有节点有一致的值。 最终一致性 像Voldemort,Cassandra和Riak这些类Dynamo的系统,通常都允许用户按需要设置N,R,W三个值,即使是设置成W+R<= N也是可以的。也就是说他允许用户在强一致性和最终一致性之间自由选择。而在用户选择了最终一致性,或者是W 3)MongoDB对隔离性(isolation)的支持 在关系型数据库中,SQL2定义了四种隔离级别,分别是READ UNCOMMITTED、READ COMMITTED、REPEATABLE READ和SERIALIZABLE。但是很少有数据库厂商遵循这些标准,比如Oracle数据库就不支持READ UNCOMMITTED和REPEATABLE READ隔离级别。而MySQL支持这全部4种隔离级别。每一种级别都规定了一个事务中所做的修改,哪些在事务内核事务外是可见的,哪些是不可见的。为了尽可能减少事务间的影响,事务隔离级别越高安全性越好但是并发就越差;事务隔离级别越低,事务请求的锁越少,或者保持锁的时间就越短,这也就是为什么绝大多数数据库系统默认的事务隔离级别是RC。 下图展示了几家不同的数据库厂商的不同事物隔离级别。 MongoDB是如何实现事务的ACID? MongoDB在3.2之前使用的是“读未提交”,这种情况下会出现“脏读”。但在MongoDB 3.2开始已经调整为“读已提交”。 下面说说每种隔离级别带来的问题: READ-UNCOMMITTED(读尚未提交的数据) 在这个级别,一个事务的修改,即使没有提交,对其他事务也都是可见的。事务可以读取未提交的数据,这也被称为“脏读(dirty read)”。这个级别会导致很多问题,从性能上来说,READ UNCOMMITTED不会比其他的级别好太多,但却缺乏其他级别的很多好处,除非真的有非常必要的理由,在实际应用中一般很少使用。 READ-COMMITTED(读已提交的数据) 在这个级别,能满足前面提到的隔离性的简单定义:一个事务开始时,只能“看见”已经提交的事务所做的修改。换句话说,一个事务从开始直到提交之前,所做的任何修改对其他事务都是不可见的。这个级别有时候也叫“不可重复读(non-repeatable read)”,因为两次执行同样的查询,可能会得到不一样的结果。 REPEATABLE-READ(可重复读) 在这个级别,保证了在同一个事务中多次读取统一记录的结果是一致的。MySQL默认使用这个级别。InnoDB和XtraDB存储引擎通过多版本并发控制MVCC(multiversion concurrency control)解决了“幻读”和“不可重复读”的问题。通过前面的学习我们知道RR级别总是读取事务开始那一刻的快照信息,也就是说这些数据数据库当前状态,这在一些对于数据的时效特别敏感的业务中,就很可能会出问题。 SERIALIZABLE(串行化) 在这个级别,它通过强制事务串行执行,避免了前面说的一系列问题。简单来说,SERIALIZABLE会在读取的每一行数据上都加锁,所以可能导致大量的超时和锁争用的问题。实际应用中也很少在本地事务中使用SERIALIABLE隔离级别,主要应用在InnoDB存储引擎的分布式事务中。 4)MongoDB对持久性(durability)的支持 对于数据持久性来说,在传统数据库中(单机)的表现为服务器任何时候发生宕机都不需要担心数据丢失的问题,因为有方式可以把数据永久保存起来了。一般都是通过日志来保证数据的持久性。通过下图来看一下传统数据库跟MongoDB对于数据持久性各自所使用的方式。 MongoDB是如何实现事务的ACID? 从上图可以看出,MongoDB同样是使用数据进来先写日志(日志刷盘的速度是非常快)然后在写入到数据库中的这种方式来保证数据的持久性,如果出现服务器宕机,当启动服务器时会从日志中读取数据。不同的是传统数据库这种方式叫做“WAL” Write-Ahead Logging(预写日志系统),而MongoDB叫做“journal”。此外MongoDB在数据持久性上这点可能做的更好,MongoDB的复制默认节点就是三节点以上的复制集群,当数据到达主节点之后会马上同步到从节点上去。

景凌凯 2019-12-02 02:05:12 0 浏览量 回答数 0

问题

【精品问答】Java技术1000问(1)

问问小秘 2019-12-01 21:57:43 37578 浏览量 回答数 11

问题

Nginx性能为什么如此吊

小柒2012 2019-12-01 21:20:47 15038 浏览量 回答数 3

问题

HBase运维基础——元数据逆向修复原理

pandacats 2019-12-18 15:08:35 3 浏览量 回答数 0
阿里云大学 云服务器ECS com域名 网站域名whois查询 开发者平台 小程序定制 小程序开发 国内短信套餐包 开发者技术与产品 云数据库 图像识别 开发者问答 阿里云建站 阿里云备案 云市场 万网 阿里云帮助文档 免费套餐 开发者工具 企业信息查询 小程序开发制作 视频内容分析 企业网站制作 视频集锦 代理记账服务 2020阿里巴巴研发效能峰会 企业建站模板 云效成长地图 高端建站