精华内容
参与话题
问答
  • nginx之平滑升级详解

    万次阅读 2015-09-22 19:15:39
    最近感觉公司的nginx版本太低了并且我们又要添加新的nginx模块所以只能想到的就是平滑升级这一个办法了。Nginx更新真的很快,最近nginx的0.8.55和nginx的0.7.69旧的稳定版本已经发布。我一项比较喜欢使用新版本的...

    最近感觉公司的nginx版本太低了并且我们又要添加新的nginx模块所以只能想到的就是平滑升级这一个办法了。Nginx更新真的很快,最近nginx的0.8.55和nginx的0.7.69旧的稳定版本已经发布。我一项比较喜欢使用新版本的软件,于是把原来的nginx-1.0.2平滑升级至nginx-1.0.5稳定版。并记录这一过程,希望对有需要的朋友有点帮助。

    1. 开始之前先查看一下当前使用的版本。

    # /usr/local/nginx/sbin/nginx -V
    nginx: nginx version: nginx/1.0.5
    nginx: built by gcc 4.1.2 20080704 (Red Hat 4.1.2-50)
    nginx: TLS SNI support disabled
    nginx: configure arguments: --user=www --group=www --prefix=/usr/local/nginx --with-http_stub_status_module --with-http_ssl_module --with-http_flv_module --with-cc-opt=-O3 --with-cpu-opt=opteron --with-http_gzip_static_module
    

    ※ 注意红色区域,这是以前编译的参数。马上编辑新版本需要用到。

    2.下载新版本:http://nginx.org/en/download.html

    然后:解压 > 便以前的准备 > 编译

    # tar zxvf nginx-1.0.5.tar.gz
    # cd nginx-1.0.5
    # ./configure 
    --user=www 
    --group=www 
    --prefix=/usr/local/nginx 
    --with-http_stub_status_module 
    --with-http_ssl_module 
    --with-http_flv_module 
    --with-cc-opt='-O3' 
    --with-cpu-opt=opteron 
    --with-http_gzip_static_module
    # make

    3. 执行完后,这里不用在 make install 了,接下来重名/sbin/nginx为nginx.old

    # mv /usr/local/nginx/sbin/nginx /usr/local/nginx/sbin/nginx.old

    4. 复制编译后objs目录下的nginx文件到nginx的安装目录sbin/下

    # cp objs/nginx /usr/local/nginx/sbin/

    5. 测试一下新复制过来文件生效情况:

    # /usr/local/nginx/sbin/nginx -t
    nginx: the configuration file /usr/local/nginx/conf/nginx.conf syntax is ok
    nginx: configuration file /usr/local/nginx/conf/nginx.conf test is successful

    6. 让nginx把nginx.pid文件修改成nginx.pid.oldbin,随即启动nginx,实现不间断服务运行

    # kill -USR2 `cat /usr/local/nginx/nginx.pid`(发送平滑升级信号将旧的nginx.pid文件添加后缀nginx.pid.oldbin)
    #kill  -WINCH(平缓停止worker process) `cat /usr/local/nginx/nginx.pid.oldbin
    # kill -QUIT `cat /usr/local/nginx/nginx.pid.oldbin`

    7. 升级完成了,最后在看一下升级后的版本

    # /usr/local/nginx/sbin/nginx -v
    nginx: nginx version: nginx/1.0.5
    展开全文
  • mysql秒级平滑升级

    千次阅读 2018-03-19 16:15:01
    原url: http://www.thebigdata.cn/JieJueFangAn/32349.html一、缘起 (1)并发量大,流量大的互联网架构,一般来说,数据库上层都有一个服务层,服务层记录了“业务库名”与“数据库实例”的映射关系,通过数据库...

    原url:     http://www.thebigdata.cn/JieJueFangAn/32349.html

    一、缘起

      (1)并发量大,流量大的互联网架构,一般来说,数据库上层都有一个服务层,服务层记录了“业务库名”与“数据库实例”的映射关系,通过数据库连接池向数据库路由sql语句以执行:

    数据库连接池

      如上图:服务层配置用户库user对应的数据库实例物理位置为ip(其实是一个内网域名)。

      (2)随着数据量的增大,数据要进行水平切分,分库后将数据分布到不同的数据库实例(甚至物理机器)上,以达到降低数据量,增强性能的扩容目的:

    增强性能的扩容

      如上图:用户库user分布在两个实例上,ip0和ip1,服务层通过用户标识uid取模的方式进行寻库路由,模2余0的访问ip0上的user库,模2余1的访问ip1上的user库。

      关于数据库水平切分,垂直切分的更多细节,详见《一分钟掌握数据库垂直拆分》 。

      (3)互联网架构需要保证数据库高可用,常见的一种方式,使用双主同步+keepalived+虚ip的方式保证数据库的可用性:

    两个相互同步的主库使用相同的虚ip

      如上图:两个相互同步的主库使用相同的虚ip。

    主库挂掉的时候,虚ip自动漂移到另一个主库

      如上图:当主库挂掉的时候,虚ip自动漂移到另一个主库,整个过程对调用方透明,通过这种方式保证数据库的高可用。

      关于高可用的更多细节,详见《究竟啥才是互联网架构“高可用”》。

      (4)综合上文的(2)和(3),线上实际的架构,既有水平切分,又有高可用保证,所以实际的数据库架构是这样的:

    数据库架构

      提问:如果数据量持续增大,分2个库性能扛不住了,该怎么办呢?

      回答:继续水平拆分,拆成更多的库,降低单库数据量,增加库主库实例(机器)数量,提高性能。

      最终问题抛出:分成x个库后,随着数据量的增加,要增加到y个库,数据库扩容的过程中,能否平滑,持续对外提供服务,保证服务的可用性,是本文要讨论的问题。

      二、停服务方案

      在讨论平滑方案之前,先简要说明下“x库拆y库”停服务的方案:

      (1)站点挂一个公告“为了为广大用户提供更好的服务,本站点/游戏将在今晚00:00-2:00之间升级,届时将不能登录,用户周知”

      (2)停服务

      (3)新建y个库,做好高可用

      (4)数据迁移,重新分布,写一个数据迁移程序,从x个库里导入到y个库里,路由规则由%x升级为%y

      (5)修改服务配置,原来x行配置升级为y行

      (6)重启服务,连接新库重新对外提供服务

      整个过程中,最耗时的是第四步数据迁移。

      回滚方案:

      如果数据迁移失败,或者迁移后测试失败,则将配置改回x库,恢复服务,改天再挂公告。

      方案优点:简单

      方案缺点:

      (1)停服务,不高可用

      (2)技术同学压力大,所有工作要在规定时间内做完,根据经验,压力越大约容易出错(这一点很致命)

      (3)如果有问题第一时间没检查出来,启动了服务,运行一段时间后再发现有问题,难以回滚,需要回档,可能会丢失一部分数据

      有没有更平滑的方案呢?

      三、秒级、平滑、帅气方案

    扩容前的架构

      再次看一眼扩容前的架构,分两个库,假设每个库1亿数据量,如何平滑扩容,增加实例数,降低单库数据量呢?三个简单步骤搞定。

      (1)修改配置

    修改配置

      主要修改两处:

      a)数据库实例所在的机器做双虚ip,原来%2=0的库是虚ip0,现在增加一个虚ip00,%2=1的另一个库同理

      b)修改服务的配置(不管是在配置文件里,还是在配置中心),将2个库的数据库配置,改为4个库的数据库配置,修改的时候要注意旧库与辛苦的映射关系:

      %2=0的库,会变为%4=0与%4=2;

      %2=1的部分,会变为%4=1与%4=3;

      这样修改是为了保证,拆分后依然能够路由到正确的数据。

      (2)reload配置,实例扩容

    reload配置,实例扩容

      服务层reload配置,reload可能是这么几种方式:

      a)比较原始的,重启服务,读新的配置文件

      b)高级一点的,配置中心给服务发信号,重读配置文件,重新初始化数据库连接池

      不管哪种方式,reload之后,数据库的实例扩容就完成了,原来是2个数据库实例提供服务,现在变为4个数据库实例提供服务,这个过程一般可以在秒级完成。

      整个过程可以逐步重启,对服务的正确性和可用性完全没有影响:

      a)即使%2寻库和%4寻库同时存在,也不影响数据的正确性,因为此时仍然是双主数据同步的

      b)服务reload之前是不对外提供服务的,冗余的服务能够保证高可用

      完成了实例的扩展,会发现每个数据库的数据量依然没有下降,所以第三个步骤还要做一些收尾工作。

      (3)收尾工作,数据收缩

    数据收缩

      有这些一些收尾工作:

      a)把双虚ip修改回单虚ip

      b)解除旧的双主同步,让成对库的数据不再同步增加

      c)增加新的双主同步,保证高可用

      d)删除掉冗余数据,例如:ip0里%4=2的数据全部干掉,只为%4=0的数据提供服务啦

      这样下来,每个库的数据量就降为原来的一半,数据收缩完成。

      四、总结

    n库扩2n库的秒级、平滑扩容

      该帅气方案能够实现n库扩2n库的秒级、平滑扩容,增加数据库服务能力,降低单库一半的数据量,其核心原理是:成倍扩容,避免数据迁移。

      迁移步骤:

      (1)修改配置

      (2)reload配置,实例扩容完成

     

      (3)删除冗余数据等收尾工作,数据量收缩完成


    展开全文
  • 平滑升级的概念

    2016-05-12 18:29:00
    转载于:https://www.cnblogs.com/yangliw3/p/5486865.html

    image

    转载于:https://www.cnblogs.com/yangliw3/p/5486865.html

    展开全文
  • 2019独角兽企业重金招聘Python工程师标准>>> ...

    一、问题的提出

    互联网有很多“数据量较大,并发量较大,业务复杂度较高”的业务场景,其典型系统分层架构如下:

    640?wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1

    (1)上游是业务层biz,实现个性化的业务逻辑

    (2)中游是服务层service,封装数据访问

    (3)下游是数据层db,存储固化的业务数据

     

    服务化分层架构的好处是,服务层屏蔽下游数据层的复杂性,例如缓存、分库分表、存储引擎等存储细节不需要向调用方暴露,而只向上游提供方便的RPC访问接口,当有一些数据层变化的时候,所有的调用方也不需要升级,只需要服务层升级即可。

     

    互联网架构,很多时候面临着这样一些需求:

    640?wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1

    需求1->底层表结构变更:数据量非常大的情况下,数据表增加了一些属性,删除了一些属性,修改了一些属性。

     

    640?wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1

    需求2->分库个数变换:由于数据量的持续增加,底层分库个数非成倍增加。

     

    640?wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1

    需求3->底层存储介质变换:底层存储引擎由一个数据库换为另一个数据库。

     

    种种需求,都需要进行数据迁移,如何平滑迁移数据,迁移过程不停机,保证系统持续服务,是文本将要讨论的问题

     

    二、停机方案

    在讨论平滑迁移数据方案之前,先看下不平滑的停机数据迁移方案,主要分三个步骤。

    640?wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1

    步骤一一个类似“为了给广大用户提供更好的服务,服务器会在凌晨0:00-0:400进行停机维护”的公告,并在对应时段进行停机,这个时段系统没有流量进入。

     

    640?wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1

    步骤二:停机后,研发一个离线的数据迁移工具,进行数据迁移。针对第一节的三类需求,会分别开发不同的数据迁移工具。

    (1)底层表结构变更需求:开发旧表导新表的工具

    (2)分库个数变换需求:开发2库导3库的工具

    (3)底层存储介质变换需求:开发Mongo导Mysql工具

     

    293ec00e9d813edf3fae970931cfa4769e7.jpg

    步骤三恢复服务,并将流量切到新库,不同的需求,可能会涉及不同服务升级。

    (1)底层表结构变更需求:服务要升级到访问新表

    (2)分库个数变换需求:服务不需要升级,只需要改寻库路由配置

    (3)底层存储介质变换需求:服务升级到访问新的存储介质

     

    总的来说,停机方案是相对直观和简单的,但对服务的可用性有影响,许多游戏公司的服务器升级,游戏分区与合区,可能会采用类似的方案。

     

    除了影响服务的可用性,这个方案还有一个缺点,就是必须在指定时间完成升级,这个对研发、测试、运维同学来说,压力会非常大,一旦出现问题例如数据不一致,必须在规定时间内解决,否则只能回滚。根据经验,人压力越大越容易出错,这个缺点一定程度上是致命的。

     

    无论如何,停机方案并不是今天要讨论的重点,接下来看一下常见的平滑数据迁移方案

     

    三、平滑迁移-追日志法

    平滑迁移方案一,追日志法,这个方案主要分为五个步骤。

    640?wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1

    数据迁移前,上游业务应用通过旧的服务访问旧的数据。

     

    640?wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1

    步骤一:服务进行升级,记录“对旧库上的数据修改”的日志(这里的修改,为数据的insert, delete, update),这个日志不需要记录详细数据,主要记录:

    (1)被修改的库

    (2)被修改的表

    (3)被修改的唯一主键

    具体新增了什么行,修改后的数据格式是什么,不需要详细记录。这样的好处是,不管业务细节如何变化,日志的格式是固定的,这样能保证方案的通用性。

     

    这个服务升级风险较小:

    (1)写接口是少数接口,改动点较少

    (2)升级只是增加了一些日志,对业务功能没有任何影响

     

    640?wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1

    步骤二研发一个数据迁移工具,进行数据迁移。这个数据迁移工具和离线迁移工具一样,把旧库中的数据转移到新库中来。

     

    这个小工具的风险较小:

    (1)整个过程依然是旧库对线上提供服务

    (2)小工具的复杂度较低

    (3)任何时间发现问题,都可以把新库中的数据干掉重来

    (4)可以限速慢慢迁移,技术同学没有时间压力

     

    数据迁移完成之后,就能够切到新库提供服务了么?

    答案是否定的,在数据迁移的过程中,旧库依然对线上提供着服务,库中的数据随时可能变化,这个变化并没有反映到新库中来,于是旧库和新库的数据并不一致,所以不能直接切库,需要将数据追平。

     

    哪些数据发生了变化呢?

    步骤一中日志里记录的不就是么?

     

    270f74efea77b58008c62b96733caed9841.jpg

    步骤三研发一个读取日志并迁移数据的小工具,要把步骤二迁移数据过程中产生的差异数据追平。这个小工具需要做的是:

    (1)读取日志,得到哪个库、哪个表、哪个主键发生了变化

    (2)把旧库中对应主键的记录读取出来

    (3)把新库中对应主键的记录替换掉

    无论如何,原则是数据以旧库为准

     

    这个小工具的风险也很小:

    (1)整个过程依然是旧库对线上提供服务

    (2)小工具的复杂度较低

    (3)任何时间发现问题,大不了从步骤二开始重来

    (4)可以限速慢慢重放日志,技术同学没有时间压力

     

    日志重放之后,就能够切到新库提供服务了么?

    答案依然是否定的,在日志重放的过程中,旧库中又可能有数据发生了变化,导致数据不一致,所以还是不能切库,需要进一步读取日志,追平记录。可以看到,重放日志追平数据的程序是一个while(1)的程序,新库与旧库中的数据追平也会是一个“无限逼近”的过程

     

    什么时候数据会完全一致呢?

     

    640?wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1

    步骤四:在持续重放日志,追平数据的过程中,研发一个数据校验的小工具,将旧库和新库中的数据进行比对,直到数据完全一致

     

    这个小工具的风险依旧很小:

    (1)整个过程依然是旧库对线上提供服务

    (2)小工具的复杂度较低

    (3)任何时间发现问题,大不了从步骤二开始重来

    (4)可以限速慢慢比对数据,技术同学没有时间压力

     

    640?wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1

    步骤五:在数据比对完全一致之后,将流量迁移到新库,新库提供服务,完成迁移。

     

    如果步骤四数据一直是99.9%的一致,不能完全一致,也是正常的,可以做一个秒级的旧库readonly,等日志重放程序完全追上数据后,再进行切库切流量。

     

    至此,升级完毕,整个过程能够持续对线上提供服务,不影响服务的可用性。

     

    四、平滑迁移-双写法

    平滑迁移方案二,双写法,这个方案主要分为四个步骤。

    640?wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1

    数据迁移前,上游业务应用通过旧的服务访问旧的数据。

     

    ebec98346c0ab450b9c601b3839b25c6f21.jpg

    步骤一服务进行升级,对“对旧库上的数据修改”(这里的修改,为数据的insert, delete, update),在新库上进行相同的修改操作,这就是所谓的“双写”,主要修改操作包括:

    (1)旧库与新库的同时insert

    (2)旧库与新库的同时delete

    (3)旧库与新库的同时update

    由于新库中此时是没有数据的,所以双写旧库与新库中的affect rows可能不一样,不过这完全不影响业务功能,只要不切库,依然是旧库提供业务服务

     

    这个服务升级风险较小:

    (1)写接口是少数接口,改动点较少

    (2)新库的写操作执行成功与否,对业务功能没有任何影响

     

    26d53cdaa97daec09b0667bbbf62e995d9b.jpg

    步骤二:研发一个数据迁移工具,进行数据迁移。这个数据迁移工具在本文中已经出现第三次了,把旧库中的数据转移到新库中来。

     

    这个小工具的风险较小:

    (1)整个过程依然是旧库对线上提供服务

    (2)小工具的复杂度较低

    (3)任何时间发现问题,都可以把新库中的数据干掉重来

    (4)可以限速慢慢迁移,技术同学没有时间压力

     

    数据迁移完成之后,就能够切到新库提供服务了么?

    答案是肯定的,因为前置步骤进行了双写,所以理论上数据迁移完之后,新库与旧库的数据应该完全一致。

     

    由于迁移数据的过程中,旧库新库双写操作在同时进行,怎么证明数据迁移完成之后数据就完全一致了呢?

     

    640?wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1

    如上图所示:

    (1)左侧是旧库中的数据,右侧是新库中的数据

    (2)按照primary key从min到max的顺序,分段,限速进行数据的迁移,假设已经迁移到now这个数据段

     

    数据迁移过程中的修改操作分别讨论:

    (1)假设迁移过程中进行了一个双insert操作,旧库新库都插入了数据,数据一致性没有被破坏

    (2)假设迁移过程中进行了一个双delete操作,这又分为两种情况

             (2.1)假设这delete的数据属于[min,now]范围,即已经完成迁移,则旧库新库都删除了数据,数据一致性没有被破坏

             (2.2)假设这delete的数据属于[now,max]范围,即未完成迁移,则旧库中删除操作的affect rows为1,新库中删除操作的affect rows为0,但是数据迁移工具在后续数据迁移中,并不会将这条旧库中被删除的数据迁移到新库中,所以数据一致性仍没有被破坏

    (3)假设迁移过程中进行了一个双update操作,可以认为update操作是一个delete加一个insert操作的复合操作,所以数据仍然是一致

     

    除非除非除非,在一种非常非常非常极限的情况下:

    (1)date-migrate-tool刚好从旧库中将某一条数据X取出

    (2)在X插入到新库中之前,旧库与新库中刚好对X进行了双delete操作

    (3)date-migrate-tool再将X插入到新库中

    这样,会出现新库比旧库多出一条数据X。

     

    但无论如何,为了保证数据的一致性,切库之前,还是需要进行数据校验的。

     

    640?wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1

    步骤三:在数据迁移完成之后,需要使用数据校验的小工具,将旧库和新库中的数据进行比对,完全一致则符合预期,如果出现步骤二中的极限不一致情况,则以旧库中的数据为准。

     

    这个小工具的风险依旧很小:

    (1)整个过程依然是旧库对线上提供服务

    (2)小工具的复杂度较低

    (3)任何时间发现问题,大不了从步骤二开始重来

    (4)可以限速慢慢比对数据,技术同学没有时间压力

     

    be7206a51c20e39c7cb71b8feceb5120889.jpg

    步骤四:数据完全一致之后,将流量切到新库,完成平滑数据迁移。

     

    至此,升级完毕,整个过程能够持续对线上提供服务,不影响服务的可用性。

     

    五、总结

    针对互联网很多“数据量较大,并发量较大,业务复杂度较高”的业务场景,在

    (1)底层表结构变更

    (2)分库个数变换

    (3)底层存储介质变换

    的众多需求下,需要进行数据迁移,完成“平滑迁移数据,迁移过程不停机,保证系统持续服务”有两种常见的解决方案。

     

    追日志法,五个步骤:

    (1)服务进行升级记录“对旧库上的数据修改”的日志

    (2)研发一个数据迁移小工具,进行数据迁移

    (3)研发一个读取日志小工具追平数据差异

    (4)研发一个数据比对小工具校验数据一致性

    (5)流量切到新库,完成平滑迁移

     

    双写法,四个步骤:

    (1)服务进行升级,记录“对旧库上的数据修改”进行新库的双写

    (2)研发一个数据迁移小工具,进行数据迁移

    (3)研发一个数据比对小工具校验数据一致性

    (4)流量切到新库,完成平滑迁移

    转载于:https://my.oschina.net/u/2607135/blog/2120599

    展开全文
  • 1.Nginx平滑升级概述 1.1 什么是平滑升级 在进行服务版本升级的时候,对于用户访问体验无感知、不 会造成服务中断。 1.2 Nginx进行平滑升级的原理 1.3 如何实现Nginx平滑升级思路(建议准备一个大文件持续下载...
  • 客户端平滑升级的两种思路.

    千次阅读 2018-08-08 17:10:09
     需要 全体升级,然后一键切换. 让一方用户提示另外一方. 投屏:  智能设备从6位码变成 5位数字码.  异步: 方案先埋, 等95%升级完毕后. 切换智能设备的方案. 显示文案.  同步: 智能设备端提供切换入口,h5扫码...
  • nginx的平滑升级

    千次阅读 2019-01-06 13:49:14
    关于nginx,我们通常都会提到nginx的平滑升级。即在不影响业务的情况下,对正在使用的nginx的版本进行升级。而这个操作是只在有必要升级时才进行的。 关于nginx的平滑升级与nginx添加模块基本相同,可参考下列链接...
  • 一旦一个服务 kill 不往这个服务上转发请求,不过这样好像还是有一个问题,我要升级必然要 kill 掉一个服务,kill 瞬间如果还有请求在这个实例里,那么这个请求就无法返回数据,这样用户感知到异常了。 所以最好的...
  • nginx平滑升级完整版

    2020-09-08 16:50:54
    nginx平滑升级完整版 前言:因公司漏洞扫描发现高危漏洞,要求修复漏洞 nginx resolver 释放后重利用漏洞(CVE-2016-0746)修复,拿到这个漏洞的时候整个人都是懵的,wc,我才两年多Java开发工作经验需要我升级服务器...
  • nginx平滑升级

    千次阅读 2018-06-17 00:20:51
    nginx平滑升级 nginx在编译安装完成之后,出于以下两种考虑都需要进行升级: 版本更新 添加未编译安装的模块 而nginx所采用的平滑升级可以保证在不停止服务的情况下解决以上问题。我们以动态增加–with-...
  • (1)含义:在线上业务不停止的情况下,进行nginx升级。 (2)过程:①、在不停掉老进程的情况下,启动新进程。 ②、老进程负载处理没有处理完的请求,但不接受新的处理请求。 ③、新进程接受新请求。 ④、老...
  • nginx平滑升级问题

    2017-06-15 11:08:23
    首先查看现在环境nginx的版本为1.12.0 编译的参数只指定了安装路径;   复制代码代码如下: [root@localhost sbin]# ./nginx -V nginx version: nginx/1.6.2 built by gcc 4.4.7 20120313 (Red Hat 4.4.7-11) ...
  • nginx平滑升级、回退

    2019-10-31 23:11:58
    1:nginx平滑升级、回退 #升级 1)首先将之前的1.14版本的启动脚本备份 cd /usr/local/nginx/sbin cp nginx nginx.old 2)再编译新版本1.15 'configure make结束不要make install,这会覆盖原来的nginx' cd ...
  • Nginx 平滑升级 nginx路径:/usr/local/nginx 升级前:nginx 1.4.4 升级后:openresty 1.15.8.3 升级步骤 1. 下载openresty wget https://openresty.org/download/openresty-1.15.8.3.tar.gz tar -xzvf openresty-...
  • Nginx平滑升级源码分析

    千次阅读 2017-10-13 20:58:32
    一、平滑升级步骤 1、重命名之前的sbin/nginx文件,将新的nginx文件放到sbin/目录下 #mv ./sbin/nginx ./sbin/nginx.old #cp ~/nginx ./sbin/ 2、向正在运行的nginx发送USR2信号启动新的nginx
  • nginx平滑升级

    2020-09-20 21:45:20
    nginx平滑升级 启动时绝对路径启动,否则省升级时 kill -USR2 cat /var/run/nginx.pid 会报错,因为这时会赵一个绝对路径启动。 failed while executing new binary process “nginx” (2: No such file or ...
  • Nginx平滑升级

    2020-10-23 11:30:25
    伴随着nginx的广泛应用,版本升级必然是越来越快的,线上业务不能停,此时nginx的升级就是运维的重要工作了,下面就带大家一起来理解下nginx平滑升级。 .nginx平滑升级的原理 ①、多进程模式下的请求分配模式 nginx...
  • nginx平滑升级(热部署)

    千次阅读 2019-02-25 10:58:41
    nginx的热部署(平滑升级) 原理: Ngnix中的进程分为两类,一类是master进程(主进程),一类是worker进程(工作进程)。 原理就是首先我们先会替换master进程,同时我们替换的master是与老版本的...
  • nginx 平滑升级

    2016-08-21 13:29:08
    Nginx实现了平滑升级, 在不停掉老进程的情况下,启动新进程。老进程负责处理仍然没有处理完的请求,但不再接受处理请求,新进程接受新请求。 老进程处理完所有请求,关闭所有连接后,停止。 一般有两种情况下需要升级...
  • 问题是服务器上运行着很多服务,如何平滑的进行升级呢?接下来看我表演,哈哈 第一步 准备工作 1 查看当前的版本信息: 执行如下命令:/usr/local/nginx/sbin/nginx -V nginx version: nginx/1.1.10 built by gcc 4...

空空如也

1 2 3 4 5 ... 20
收藏数 27,970
精华内容 11,188
关键字:

平滑升级