nginx 故障转移

当我们的服务器某台出现问题的时候,怎么办。。。。

nginx在反向代理到真实服务器(上游服务器)的时候,如果真实服务器出现了宕机,或延迟卡顿的情况下,直接轮询下一个节点。

其中主要配置如下:

       ###nginx与上游服务器(真实访问的服务器)超时时间 后端服务器连接的超时时间_发起握手等候响应超时时间
            proxy_connect_timeout 2s;
            ###nginx发送给上游服务器(真实访问的服务器)超时时间
            proxy_send_timeout 2s;
            ### nginx接受上游服务器(真实访问的服务器)超时时间
            proxy_read_timeout 2s;
upstream  backServerAAA{
        server 127.0.0.1:8080;
        server 127.0.0.2:8080;
        server 127.0.0.3:8080;
        server 127.0.0.4:8080;
        server 127.0.0.5:8080;
        server 127.0.0.6:8080;
}

server {
        listen       80;
        server_name  www.a393060727.com;
        location / {
            ### 指定上游服务器负载均衡服务器
            proxy_pass http://backServerAAA;
            index  index.html index.htm;
            ###nginx与上游服务器(真实访问的服务器)超时时间 后端服务器连接的超时时间_发起握手等候响应超时时间
            proxy_connect_timeout 2s;
            ###nginx发送给上游服务器(真实访问的服务器)超时时间
            proxy_send_timeout 2s;
            ### nginx接受上游服务器(真实访问的服务器)超时时间
            proxy_read_timeout 2s;

        }
    }

原文地址:https://www.cnblogs.com/a393060727/p/12043516.html

时间: 2024-10-08 14:33:34

nginx 故障转移的相关文章

CentOS 6.5安装lvs+keepalive负载均衡+故障转移nginx

环境 192.168.1.219为keepalived和lvs的VIP地址 192.168.1.222为keepalived的主并安装ipvsadm 192.168.1.221为keepalived的从并安装ipvsadm 192.168.1.218为nginx web服务器 192.168.1.220为nginx web服务器 在192.168.1.222下载keepalived和ipvsadm mkdir /root/repo cd /root/repo wget http://www.li

5-4keepalived与nginx实现高可用故障转移实战

回顾:keepalived:HA Cluster高可用集群的实现vrrp:虚拟冗余路由协议虚拟路由器:物理路由器VRID:Virtual Router IDMaster/Backup一主一备货一主多备priority抢占模式/非抢占模式ipvs wrapper(checkers);checkers:对各VS的各RS做健康状态检测应用层检测:HTTP_GET,SSL_GET,SMTP_CHECK传输层检测:TCP_CHECK自定义检测:MISC_CHECK(例如mysql数据检测),自定义脚本检测

负载均衡和故障转移 连载

负载均衡和故障转移 1.任务目标 本次任务是要解决服务器负载均衡和故障转移,此负载均衡是要实现真正意义上的负载均衡,对实际使用中,根据服务器的各种性能指标进行任务分配,以达到响应速度快.体验高的效果.其次,故障转移是对负载均衡的补充,对实现快速响应和高可用性进行结合.本次任务的目标不只包括实现,并且还需要尽量避免硬件的改变和添加,以软件层面去实现,减少实施成本. 任务环境是Windows Server 2008 R2 ,IIS7.0以上. 2.解决方案 由于环境是在Windows, 考虑到兼容性

failover swarm 故障转移

#故障转移 Failover #当其中一个节点关闭宕机时,其节点中的service会转移到另一个节点上.Swarm会检测到node1发生故障并把此故障节点的状态标记为Down; docker node ls 可查看 node1的STATUS 为Down同时 Swarm会把node1上的service调度到其它有资源的节点上来运行:docker service ps web_server 可查看其过程和状态 #访问server #便于分析,重新部署一个 docker service create

部署AlwaysOn第一步:搭建Windows服务器故障转移集群

在Windows Server 2012 R2 DataCenter 环境中搭建集群之前,首先要对Windows服务器故障转移集群(Windows Server Failover Cluster,简称WSFC)有基本的了解.WSFC必须部署在域管理环境中,由多台服务器组成,每台服务器称作一个"结点"(Node),每个结点上都运行了Windows服务器故障转移集群服务,整个集群系统允许部分结点掉线.故障或损坏而不影响整个系统的正常运作.集群自动检测结点的健康状态,一旦活跃结点发生异常,变

测试ReplicaSets读写分离和故障转移

读写分离实现步骤: 从库能够进行查询就更好了,这样可以分担主库的大量的查询请求. 1) 先向主库中插入一条测试数据 rs1:PRIMARY> db.c1.insert({age:30});db.c1.insert({age:30}); WriteResult({ "nInserted" : 1 }) rs1:PRIMARY>  db.c1.find() db.c1.find() { "_id" : ObjectId("5791ef011f4c6

12.5 手动故障转移

12.5 手动故障转移 12.5.1 禁用作业 禁用主服务器的备份作业,禁用辅助服务器上的复制作业和还原作业,禁用监视服务器上的警报作业. 12.5.2 还原辅助数据库 将所有末复制的备份文件从备份共享文件夹复制到辅助服务器的复制目标文件夹. 将所有末应用的事务日志备份按顺序还原到辅助数据库. 如果主数据库仍可访问,则请对主数据库做一个结尾日志备份. 使用 WITH RECOVERY 选项还原辅助数据库.最终,辅助数据库将成为正常的数据库. 将此辅助数据库还原成正常数据库之后,可以将该数据库重新

SQL Server 2014 日志传送部署(7):日志传送故障转移和删除日志传送

13.4 故障转移 13.4.1 故障定位 在前几节明确的提及到,日志传送由三个基本的作业组成:备份作业.复制作业和还原作业.通过上一节日志传送监控功能来定位哪一个作业出了问题: 如果备份作业出了问题,检查主服务器状态. 如果还原作业出了问题,检查辅助服务器状态:或者辅助数据库处于STANDBY模式时用户正在使用辅助数据库. 如果复制作业出了问题,检查除了辅助服务器状态外,还需要检查网络状态. 13.4.2 故障转移 日志传送的故障转移除了考虑切换技术操作以外,更需要考虑主服务器和辅助服务器之间

修改故障转移群集心跳时间

Windows Server Failover Clustering is a high availability platform that is constantly monitoring the network connections and health of the nodes in a cluster.  If a node is not reachable over the network, then recovery action is taken to recover and