本文详细介绍了Openstack的网络原理和实现,主要内容包括:Neutron的网络架构及网络模型还有neutron虚拟化的实现和对二三层网桥的理解。
一、Neutron概述
Neutron是一个用Python写的分布式软件项目,用来实现OpenStack中的虚拟网络服务,实现软件定义网络。Neutron北向有自己的REST API,中间有自己的业务逻辑层,有自己的DB和进程之间通讯的消息机制。同时Neutron常见的进程包括Neutron-server和Neutron-agent,分布式部署在不同的 *** 作系统。
OpenStack发展至今,已经经历了20个版本。虽然版本一直在更替,发展的项目也越来越多,但是Neutron作为OpenStack三大核心之一,它的地位是不会动摇的。只不过当初的Neutron也只是Nova项目的一个模块而已,到F版本正式从中剥离,成为一个正式的项目。
从Nova-Network起步,经过Quantum,多年的积累Neutron在网络各个方面都取得了长足的发展。其主要的功能为:
(1)支持多租户隔离
(2)支持多种网络类型同时使用
(3)支持隧道技术(VXLAN、GRE)
(4)支持路由转发、SNAT、DNAT技术
(5)支持Floating IP和安全组
多平面租户私有网络
图中同时有VXLAN和VLAN两种网络,两种网络之间互相隔离。租户A和B各自独占一个网络,并且通过自己的路由器连接到了外部网络。路由器为租户的每个虚拟机提供了Float IP,完成vm和外网之间的互相访问。
二、Neutron架构及网络模型
1、Neutron架构
Neutron-sever可以理解为类似于nova-api那样的一个专门用来接收API调用的组件,负责将不同的api发送到不同Neutron plugin。
Neutron-plugin可以理解为不同网络功能实现的入口,接收server发来的API,向database完成一些注册信息。然后将具体要执行的业务 *** 作和参数通知给对应的agent来执行。
Agent就是plugin在设备上的代理,接受相应的plugin通知的业务 *** 作和参数,并转换为具体的命令行 *** 作。
总得来说,server负责交互接收请求,plugin *** 作数据库,agent负责具体的网络创建。
2、Neutron架构之Neutron-Server
(1)Neutron-server的本质是一个Python Web Server Gateway Interface(WSGI),是一个Web框架。
(2)Neutron-server接收两种请求:
REST API请求:接收REST API请求,并将REST API分发到对应的Plugin(L3RouterPlugin)。
RPC请求:接收Plugin agent请求,分发到对应的Plugin(NeutronL3agent)。
3、Neutron架构之Neutron-Plugin
Neutron-plugin分为Core-plugin和Service-plugin。
Core-plugin:ML2负责管理二层网络,ML2主要包括Network、Subnet、Port三类核心资源,对三类资源进行 *** 作的REST API是原生支持的。
Service-plugin:实现L3-L7网络,包括Router、Firewall、。
4、Neutron架构之Neutron-Agent
(1)Neutron-agent配置的业务对象是部署在每一个网络节点或者计算节点的网元。
(2)网元区分为PNF和VNF:
PNF:物理网络功能,指传统的路由器、交换机等硬件设备
VNF:虚拟网络功能,通过软件实现的网络功能(二层交换、三层路由等)
(3)Neutron-agent三层架构如下图:
Neutron-agent架构分为三层,北向为Neutron-server提供RPC接口,供Neutron server调用,南向通过CLI协议栈对Neutron VNF进行配置。在中间会进行两种模型的转换,从RPC模型转换为CLI模型。
5、Neutron架构之通信原理
(1)Neutron是OpenStack的核心组件,官网给出Neutron的定义是NaaS。
(2)Naas有两层含义:
对外接口:Neutron为Network等网络资源提供了RESTful API、CLI、GUI等模型。
内部实现:利用Linux原生或者开源的虚拟网络功能,加上硬件网络,构建网络。
Neutron接收到API请求后,交由模块WSGI进行初步的处理,然后这个模块通过Python API调用neutron的Plugin。Plugin做了相应的处理后,通过RPC调用Neutron的Agent组件,agent再通过某种协议对虚拟网络功能进行配置。其中承载RPC通信的是AMQP server,在部署中常用的开源软件就是RabbitMQ
6、Neutron架构之控制节点网络模型
控制节点没有实现具体的网络功能,它对各种虚拟设备做管理配合的工作。
(1)Neutron:Neutron-server核心组件。
(2)API/CLI:Neutron进程通过API/CLI接口接收请求。
(3)OVS Agent:Neutron通过RPC协议与agent通信。
控制节点部署着各种服务和Neutron-server,Neutron-server通过api/cli接口接收请求信息,通过RPC和Agent进行交互。Agent再调用ovs/linuxbridge等网络设备创建网络。
7、Neutron架构之计算节点网络模型
(1)qbr:Linux Bridge网桥
(2)br-int:OVS网桥
(3)br-tun:OVS隧道网桥
(4)VXLAN封装:网络类型的转变
8、Neutron架构之网络节点网络模型
网络节点部署了Router、DHCP Server服务,网桥连接物理网卡。
(1)Router:路由转发
(2)DHCP: 提供DNS、DHCP等服务。
(3)br-ex: 连接物理网口,连接外网
三、Neutron虚拟化实现功能及设备介绍
1、Neutron虚拟化实现功能
Neutron提供的网络虚拟化能力包括:
(1)二层到七层网络的虚拟化:L2(virtual Switch)、L3(virtual Router 和 LB)、L47(virtual Firewall )等
(2)网络连通性:二层网络和三层网络
(3)租户隔离性
(4)网络安全性
(5)网络拓展性
(6)REST API
(7)更高级的服务,包括 LBaaS,FWaaS,aaS 等
2、Neutron虚拟化功能之二层网络
(1)按照用户权限创建网络:
Provider network:管理员创建,映射租户网络到物理网络
Tenant network:租户创建的普通网络
External network:物理网络
(2)按照网络类型:
Flat network:所有租户网络在一个网络中
Local network:只允许在服务器内通信,不通外网
VLAN network:基于物理VLAN实现的虚拟网络
VXLAN network:基于VXLAN实现的虚拟网络
3、Neutron虚拟化实现功能之租户隔离
Neutron是一个支持多租户的系统,所以租户隔离是Neutron必须要支持的特性。
(1)租户隔离三种含义:管理面隔离、数据面的隔离、故障面的隔离。
(2)不同层次租户网络的隔离性
租户与租户之间三层隔离
同一租户不同网络之间二层隔离
同一租户同一网络不同子网二层隔离
(3)计算节点的 br-int 上,Neutron 为每个虚机连接 OVS 的 access port 分配了内部的 VLAN Tag。这种 Tag 限制了网络流量只能在 Tenant Network 之内。
(4)计算节点的 br-tun 上,Neutron 将内部的 VLAN Tag 转化为 VXLAN Tunnel ID,然后转发到网络节点。
(5)网络节点的 br-tun 上,Neutron 将 VXLAN Tunnel ID 转发了一一对应的 内部 VLAN Tag,使得 网络流被不同的服务处理。
(6)网络节点的 br-int 上连接的 DHCP 和 L3 agent 使用 Linux Network Namespace 进行隔离。
4、Neutron虚拟化实现功能之租户网络安全
除了租户隔离以外 Neutron还提供数据网络与外部网络的隔离性。
(1)默认情况下,所有虚拟机通过外网的流量全部走网络节点的L3 agent。在这里,内部的固定IP被转化为外部的浮动IP地址
(1)Neutron还利用Linux iptables特性,实现其Security Group特性,从而保证访问虚机的安全性
(3)Neutron利用网络控制节点上的Network Namespace中的iptables,实现了进出租户网络的网络防火墙,从而保证了进出租户网络的安全性。
5、Neutron虚拟化设备
(1)端口:Port代表虚拟网络交换机上的一个虚拟交换机端口
虚拟机的网卡连接到Port上就会拥有MAC地址和IP地址
(2)虚拟交换机:Neutron默认采用开源的Openvswitch,
同时还支持Linux Bridge
(3)虚拟路由器VR:
路由功能一个VR只属于一个租户,租户可以有多个VR一个VR可以有若干个子网VR之间采用Namespace隔离四、Neutron网桥及二三层网络理解
1、Neutron-Local-Bridge
仅用于测试;网桥没有与物理网卡相连VM不通外网。
图中创建了两个local network,分别有其对应的qbr网桥。Vm123的虚拟网卡通过tap连接到qbr网桥上。其中2和3属于同一个network可以通信,1属于另一个网络不能和23进行通信。并且qbr网桥不连物理网卡,所以说local网络虚拟机只能同网络通信,不能连通外网。
2、Neutron-Flat-Bridge
Linux Bridge直接与物联网卡相连每个Flat独占一个物理网卡配置文件添加响应mappingFlat网络是在local网络的基础上实现不同宿主机之间的二层互联,但是每个flat network都会占用一个宿主机的物理接口。其中qbr1对应的flatnetwork 连接 eth1 qbr2,两个网络的虚机在物理二层可以互联。其它跟local network类似。
3、Neutron-VLAN-Bridge
在基于linux bridge的vlan网络中,eht1物理网卡上创建了两个vlan接口,11连接到qbr1网桥,12连接到了qbr2网桥。在这种情况下vm通过eth11或者eth12发送到eth1的包会被打上各自的vlan id。此时vm2和vm3属于同一个network所以是互通的,vm与vm2和vm3不通。
4、Neutron-VXLAN-Bridge
这个是以Linux bridge作agent的Vxlan网络:
Vxlan网络比Vxlan网络多了个VXLAN隧道,在Openstack中创建好内部网络和实例后,agent就会在计算节点和网络节点创建一对vxlan vtep组成隧道的两个端点。
Vxlan连接在eth0网口。在网络节点多了两个组件dhcp 和router,他们分别通过一对veth与qbr网桥连接在一起,多个dhcp和路由之间使用namesapce隔离,当vm产生ping包时,发往linux 网桥qbr1,通过网桥在vxlan12上封装数据包,数据通过eth0网卡出计算节点到网络节点的eth0,在vxlan12解包。到达路由器之后经过nat地址转换,从eth1出去访问外网,由租户网络到运营商网络再到外部网络。
5、Neutron-VLAN-OVS
与Linux bridge不同,openvswitch 不是通过eth11 eth12这样的vlan接口来隔离不同的vlan,而是通过openvswitch的流表规则来指定如何对进出br-int的数据进行转发,实现不同vlan的隔离。
图中计算节点的所有虚拟机都连接在int网桥上,虚拟机分为两个网络。Int网桥会对到来的数据包根据network的不同打上vlan id号,然后转发到eth网桥,eth网桥直连物理网络。这时候流量就从计算节点到了网络节点。
网络节点的ehx int网桥的功能相似,多了一个ex网桥,这个网桥是管理提前创建好的,和物理网卡相连,ex网桥和int网桥之间通过一对patch-port相连,虚拟机的流量到达int网桥后经过路由到ex网桥。
6、Neutron-VXLAN-OVS
Vxlan的模型和vlan的模型十分相似,从表面上来看,他俩相比只有一个不同,vlan对应的是ethx网桥,而vxlan对应的是tun网桥。
在这里ethx和tun都是ovs网桥,所以说两者的差别不是实现组件的差别而是组件所执行功能的差别,ethx执行的是普通二层交换机的功能,tun执行的是vxlan中的vtep的功能,图中俩tun对应的接口ip就是vxlan的隧道终结点ip。所以说虚机的数据包在到达tun网桥之前是打的是vlan tag,而到达tun之后会发生网络类型的转换,从vlan封装为vxlan然后到达网络节点。而之前的vlan类型的网络,虚机数据包的类型一直都是vlan。
7、物理的二层与虚拟的二层(VLAN模式)
(1)物理的二层指的是:物理网络是二层网络,基于以太网协议的广播方式进行通信。
(2)虚拟的二层指的是:Neutron实现的虚拟网络也是二层网络(openstack的vm机所用的网络必须是大二层),也是基于以太网协议的广播方式进行通信,但毫无疑问的是该虚拟网络是依赖于物理的二层网络。
(3)物理二层+虚拟二层的典型代表:VLAN网络模式。
8、物理的三层与虚拟的二层(GRE模式与VXLAN模式)
(1)物理三层指的是:物理网络是三层网络,基于IP路由的方式进行通信。
(2)虚拟的二层指的是:Neutron实现的虚拟网络仍然是二层网络(openstack的vm机所用的网络必须是大二层),仍然是基于以太网的广播方式进行通信,但毫无疑问的是该虚拟机网络是依赖于物理的三层网络,这点有点类似于的概念,根本原理就是将私网的包封装起来,最终打上隧道的ip地址传输。
(3)物理三层+虚拟二层的典型代表:GRE模式与VXLAN模式。
造成gre报名官网进不去的原因可能有:
1、网速问题
2、网页负载过量,同时登陆的人太多,服务器运行不过来。
3、是不是国外网,有没有国内外网页的限制
4、密码不对
5、打开原网页时间过长,网页已过期。
6、网站更新。
gre报名官网进不去怎么办:
首先是建议大家先等等,因为最有可能是因为网速不给力或者负载过量,稍等片刻就好了。
有可能的话换一个网络环境试试。
刷新试试,每次进去了报名页面,都显示一个等待的蓝色框,然后完成100%后就再也进不去你好,可以换一个浏览器,并且关掉一切禁止插件,部分插件禁止跳转。
最后一种就只能老实的等待网站更新完成了。
1客户端拨入时出现721错误这种情况大数多原因为客户系统,如果为WINXP并且安装了SP2,则可能会出现这种情况,解决方法为:修改注册表 HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Control/Class/{4D36E972- E325-11CE-BFC1-08002bE10318}/<000x>,其中其中 <000x> 是 WAN 微型端口 (PPTP) 驱动程序的网络适配器,在此项中新建一个DWORD 值ValidateAddress,然后设置为0即可。
服务器端PPP协议配置不正确也会导致此类错误
2 客户端拨入时出现800错误
这种情况大数多原因为客户系统连接服务器时使用域名,因临时DNS无法解析而出现这种错误,可更换DNS试一下,如果还是出错此类错误,则可能是无法连接 到服务器,可能是服务器关闭或出现故障,也可能是客户电脑上的防火墙阻止了连接请求,可关闭防火墙试一下。
有些使用中转服务器连接到服务器的客户端,也可能出现此类错误,原因为中转服务器中转功能出现故障。
3 客户端拨入时出现619错误
这种情况大数多原因为客户机连接Internet的网关(如家庭宽带路由或公司上网网关路由或防火墙)NAT-T功能关闭或对支持性不好,主要是对 GRE及PPTP协议的NAT-T不支持。可打开网关路由的NAT-T功能,如果还是出现错误,则需要更换网关设备,现在市面上大多数设备已经支持。
4 客户端拨入时出现691错误
这种情况大数多原因为客户机连接服务器异常中断,因多数服务器限制一个帐户同时只有一个人使用,所以一旦异常断开,则需等待3分钟左右。有些 服务器没有设置异常断线检查功能也可能导致用户一旦异常断开后很长时间不能连接。所以解决办法为在服务器上设置异常断线检查程序或功能。( 一般静态出现691 基本上都是账号在别的设备登录了)
5 客户端拨入时出现733错误
这种情况大数多原因为客户机拨入服务器后无法获取IP地址,可修复DHCP服务器或设置静态IP地址或地址池。
6 客户端拨入时出现734 ppp链接控制协议终止
这种情况多数为服务器配置有问题,如果是PPP配置有问题,不支持MPPE加密或支持度不好。请重新编译PPP及MPPE相关程序。对于用于游戏代理的用户,可不使用加密(需在服务器端不要求加密)。( 出现734这类的 一般是账号到期或者用户名或者密码错误)
7 客户端拨入时出现718错误
拨入时用户名和密码出错误,有时也因为服务器端认证服务出现故障
8 出现628
Ip加速链接和windows拨号均不能成功的话,手机链接试试
链接尝试
1 切换运营商 电信、联通、移动
2 更换协议 pptp或l2tp
如果以上方法都不行,其他网络能正常链接的话,可能是客户当地运营商限制了协议 建议客户联系当地运营商,解除限制。
以上是链接过程中常出现的错误提示排查,欢迎同行交流现在的数据中心早已不是一座孤立的机房,而是一个建筑群。一个数据中心可以包含很多个分支数据中心,可以说是一个数据中心群,这些分支数据中心所处的位置不同,却可以通过网络互联起来,共同完成相应的业务部署。像阿里、腾讯、百度等这些大型互联网公司,为了提升客户访问体验,会在不同省会都会建立自己的数据中心分支机构,以便满足不同地区的客户访问需求,数据中心早已不再局限于一座或几座机房。
这些数据中心要协同运转,就需要相互之间交互信息,这就有了互连需求,产生了DCI网络,即Data Center Inter-connect,这里囊括了物理网络层面和逻辑网络层面的技术。要实现不同地区的数据中心互联,有多种方式:可以直接Internet互联,可以使用专线互连,也可以使用光纤直连,还可以增加一些加密手段,防止传输的数据泄露,这里衍生出了很多新的技术,本文就来讲述一下DCI相关的技术,以便大家对DCI有所了解。
实现数据中心间互通的纽带——DCI技术
DCI互联通常有三种方式。一种是网络三层互联,也称为数据中心前端网络互联,所谓“前端网络”是指数据中心面向企业园区网或企业广域网的出口,不同数据中心的前端网络通过IP技术实现互联,园区或分支的客户端通过前端网络访问各数据中心,当主用数据中心发生灾难时,前端网络将实现快速收敛,客户端通过访问备用的数据中心以保障业务连续性;一种是网络二层互联,也称为数据中心服务器网络互联,在不同的数据中心服务器网络接入层,构建一个数据中心间大二层网络,以满足服务器集群或虚拟机动态迁移等场景对二层网络接入的需求;最后一种是 SAN互联,也称为后端存储网络互联,借助DWDH、SDH等传输技术实现数据中心之间磁盘阵列的数据复制。在服务器集群技术普及之前,这三种互联方式都有自己的存在空间,但集群应用普及之后,前两种网络无法适从了。服务器集群是借助集群软件将网络上的多台服务器关联在一起,提供一致的服务,对外表现为一台逻辑服务器。集群软件需要各服务器间采用二层网络互联,才能实现无感知的虚拟机切换。如果采用三层互联,将无法实现虚拟迁移,如果采用二层打通,安全性成为最大隐患,数十个数据中心形成一个二层网络,一个广播风暴就会将所有数据中心搞瘫,所以两种方式都无法适应集群部署的应用,于是乎开始出现了很多DCI专用技术。
MPLS技术
基于MPLS技术的实现方案,要求数据中心之间互联网络是已部署为MPLS技术的核心网,这样可以直接通过VLL和VPLS完成数据中心直接的二层互联。MPLS包括二层技术和三层技术,VPLS协议就是二层技术,标准化程度很高,在很多行业都有部署应用。不过,VPLS技术比较复杂,部署及运维的管理难度较大,各种接入方式和类型都比较多,很多时候VPLS网络建好以后,很多人都不敢去动网络配置,容易出问题。在此我向大家推荐一个大数据技术交流圈: 658558542 突破技术瓶颈,提升思维能力 。VPLS在国外的网络中常见一些,而在国内VPLS的部署并不多见,更多的是三层MPLS,不过要支持服务器集群应用,就不能靠MPLS了,只能是VPLS。VPLS这种技术,其优点是基于MPLS技术可以较为简单地实现城域/广域网络的部署,缺点是需要核心网/城域网支持MPLS技术,技术复杂不便于维护。
IP隧道技术
IP隧道技术是基于IP技术,在任意IP网络开启相应二层隧道来实现数据中心互联。这个方案摆脱了数据中心之间互联链路的类型限制,是目前的发展方向。IP隧道技术核心思想是通过“MAC in IP”的方式,通过隧道技术穿越三层网络实现二层网络的互通。对MAC地址的学习通过控制平面借鉴IS-IS协议来实现,隧道封装采用类似GRE的动态封装方式,最后可以支持双归属的高可用部署方式。比如思科的OTV,H3C的EVI都是这类技术,这类技术基于IP核心网络的L2,可以完成站点的边缘设备上维护路由和转发信息,而无需改变站点内部和核心网络。即在IP网络上建立隧道,传递经过标签封装后的二层数据报文,从而实现跨数据中心的二层互通。数据中心二层互联方案很大程度上会受限于用户现有的网络类型,这一情况限制了数据中心对二层互联方案的应用推广。IP隧道技术是一种新的组网方案,能够无视互联网络的类型差异而统一组网,实现多个数据中心之间的异构网络二层互联。
VXLAN-DCI隧道技术
VXLAN是基于IP网络、采用“MAC in UDP”封装形式的二层技术,从事网络工作的对此都应该不陌生。现在如火如荼新建的数据中心,网络部分基本都采用的VXLAN技术,这是未来数据中心网络最为重要的技术之一,是实现网络虚拟化的前提。VXLAN隧道只能用于数据中心内部,实现数据中心内部虚拟机的互联。VXLAN-DCI隧道则可用来实现数据中心之间的互联,是一种新型DCI技术,这是部署在VXLAN网络中的重要技术。
从这三种技术不难看出有一个共同特点,都用到了封装,即在原始报文上再增加一层二层报文头,从而实现报文的大二层转发,实现虚拟机可以在所有数据中心之间自由迁移的功能。这些技术充分保留了原有网络的架构,在原有网络上再建设一套虚拟的大二层网络,将所有数据中心二层打通,虽然封装技术增加了报文封装,浪费掉一些网络带宽,但却解决了数据中心互联的大问题。现在SDN技术火热,SDN也可以在数据中心互联中起到很大作用。通过部署SDN,可做到d性计费,降低运维成本,简化 *** 作。未来的数据中心互联中必将看到SDN的身影。
感谢您的观看,如有不足之处,欢迎批评指正。
在此我向大家推荐一个大数据开发交流圈:
658558542 ( ☛点击即可加入群聊 )
里面整理了一大份学习资料,全都是些干货,包括大数据技术入门,大数据离线处理、数据实时处理、Hadoop 、Spark、Flink、推荐系统算法以及源码解析等,送给每一位大数据小伙伴,让自学更轻松。这里不止是小白聚集地,还有大牛在线解答!欢迎初学和进阶中的小伙伴一起进群学习交流,共同进步!
最后祝福所有遇到瓶颈的大数据程序员们突破自己,祝福大家在往后的工作与面试中一切顺利。
1 启动数据库服务器(posgres用户):
[postgres@localhost bin]$ postgres -D /opt/postgresql/data/ > /opt/postgresql/log/pg_serverlog 2>&1 &
[1] 4508
当然如果设置了环境变量
PGDATA=/opt/postgresql/data
export PGDATA
后,可使用pg_ctl工具进行启动:
[postgres@localhost log]$ pg_ctl start -l /opt/postgresql/log/pg_serverlog
pg_ctl: another server might be running; trying to start server anyway
pg_ctl: could not start server
Examine the log output
[postgres@localhost log]$
因为之前已经启动,所以打印“another server might be running”。此时,查看日志,有如下信息:
[postgres@localhost log]$ cat pg_serverlog
FATAL: lock file "postmasterpid" already exists
HINT: Is another postmaster (PID 4491) running in data directory "/opt/postgresql/data"
[postgres@localhost log]$
当然,最简的启动方式是:
[postgres@localhost ~]$ pg_ctl start
server starting
[postgres@localhost ~]$ LOG: database system was shut down at 2011-07-09 13:58:00 CST
LOG: autovacuum launcher started
LOG: database system is ready to accept connections
如果要在 *** 作系统启动时就启动PG,可以在/etc/rcd/rclocal 文件中加以下语句:
/opt/postgresql/bin/pg_ctl start -l /opt/postgresql/log/pg_serverlog -D /opt/postgresql/data
2关闭服务器
最简单方法:
[postgres@localhost ~]$ pg_ctl stop
waiting for server to shut down done
server stopped
与Oracle相同,在关闭时也可采用不同的模式,简介如下:
SIGTERM
不再允许新的连接,但是允许所有活跃的会话正常完成他们的工作,只有在所有会话都结束任务后才关闭。这是智能关闭。
SIGINT
不再允许新的连接,向所有活跃服务器发送 SIGTERM(让它们立刻退出),然后等待所有子进程退出并关闭数据库。这是快速关闭。
SIGQUIT
令 postgres 向所有子进程发送 SIGQUIT 并且立即退出(所有子进程也会立即退出),而不会妥善地关闭数据库系统。这是立即关闭。这样做会导致下次启动时的恢复(通过重放 WAL 日志)。我们推荐只在紧急的时候使用这个方法。
SIGKILL
此选项尽量不要使用,这样会阻止服务器清理共享内存和信号灯资源,那样的话你只能在启动服务器之前自己手工做这件事。另外,SIGKILL 直接把 postgres 杀掉,而不会等它把信号中继给它的子进程,因此我们还需要手工杀掉每个独立子进程。
使用方法举例:
[postgres@localhost ~]$ pg_ctl stop -o SIGTERM
LOG: received smart shutdown request
LOG: autovacuum launcher shutting down
waiting for server to shut downLOG: shutting down
LOG: database system is shut down
done
server stopped
[postgres@localhost ~]$
最快速关闭方法:kill postgres 进程
[postgres@localhost ~]$ kill -INT `head -1 /opt/postgresql/data/postmasterpid`
[postgres@localhost ~]$ LOG: received fast shutdown request
LOG: aborting any active transactions
LOG: autovacuum launcher shutting down
LOG: shutting down
LOG: database system is shut down
附:postgre启动后的进程,如下:
[postgres@localhost ~]$ ps -ef|grep post
root 4609 4543 0 13:57 pts/2 00:00:00 su - postgres
postgres 4610 4609 0 13:57 pts/2 00:00:00 -bash
postgres 4724 1 0 14:08 pts/2 00:00:00 /opt/postgresql/bin/postgres
postgres 4726 4724 0 14:08 00:00:00 postgres: writer process
postgres 4727 4724 0 14:08 00:00:00 postgres: wal writer process
postgres 4728 4724 0 14:08 00:00:00 postgres: autovacuum launcher process
postgres 4729 4724 0 14:08 00:00:00 postgres: stats collector process
postgres 4752 4610 0 14:11 pts/2 00:00:00 ps -ef
postgres 4753 4610 0 14:11 pts/2 00:00:00 grep post
[postgres@localhost ~]$
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)