CentOS 6.8防火墙的关闭以及开启

 

有的时候,我们需要对系统的防火墙进行操作,就给大家讲解一下如何开启以及关闭CentOS6.8系统下的防火墙。

输入:cat /etc/issue   查看版本

(一)通过service命令

service命令开启以及关闭防火墙为即时生效,下次重启机器的时候会自动复原。

查看防火墙状态:service iptables status  ,记得在CentOS6.8中是输入iptables,网上有些教程使用service iptable status 命令并不可行。

 

关闭防火墙:service iptables stop

 

打开防火墙:service iptables start

总结:

打开防火墙:service iptables start

关闭防火墙:service iptables stop

查看防火墙状态:service iptables status

 

(二)通过:/etc/init.d/iptables 进行操作

查看防火墙状态:/etc/init.d/iptables/status

关闭防火墙:/etc/init.d/iptables stop(这是临时关闭,关闭的是当前运行的防火墙,重启之后防火墙又会启动,因为它是开机自启动的)

这是临时关闭,关闭的是当前运行的防火墙,重启之后防火墙又会启动,因为它是开机自启动的,它相当于/etc/init.d/iptables start

(三)需要改为开机不启动,使用chkconfig命令

永久开启防火墙: chkconfig iptables on

查看状态:chkconfig –list iptables

永久关闭防火墙:

chkconfig iptables off

 

Centos6 下 Oracle12C RAC 集群环境虚拟机文件下载

本博主配置好的Centos6 下 Oracle12C RAC 集群环境虚拟机文件下载,链接:https://pan.baidu.com/s/1_xF5m7rcAuPw5LAn6rrgyA
提取码:udai 下载后,用Vmware workstation打开,即可以正常使用

Oracle的三种高可用集群方案

1 RAC(Real Application Clusters)

多个Oracle服务器组成一个共享的Cache,而这些Oracle服务器共享一个基于网络的存储。这个系统可以容忍单机/或是多机失败。不过系统内部的多个节点需要高速网络互连,基本上也就是要全部东西放在在一个机房内,或者说一个数据中心内。如果机房出故障,比如网络不通,那就坏了。所以仅仅用RAC还是满足不了一般互联网公司的重要业务的需要,重要业务需要多机房来容忍单个机房的事故。

2 Data Guard.(最主要的功能是冗灾)

Data Guard这个方案就适合多机房的。某机房一个production的数据库,另外其他机房部署standby的数据库。Standby数据库分物理的和逻辑的。物理的standby数据库主要用于production失败后做切换。而逻辑的standby数据库则在平时可以分担production数据库的读负载。

3 MAA

MAA(Maximum Availability Architecture)其实不是独立的第三种,而是前面两种的结合,来提供最高的可用性。每个机房内部署RAC集群,多个机房间用Data Guard同步。

RAC概述

共享存储文件系统(NFS),或甚至集群文件系统(如:OCFS2)主要被用于存储区域网络(所有节点直接访问共享文件系统上存储器),这就使得节点失效而不影响来自其他节点对文件系统的访问,通常,共享磁盘文件系统用于高可用集群。

Oracle RAC的核心是共享磁盘子系统,集群中所有节点必须能够访问所有数据、重做日志文件、控制文件和参数文件,数据磁盘必须是全局可用的,允许所有节点访问数据库,每个节点有它自己的重做日志和控制文件,但是其他节点必须能够访问它们以便在那个节点出现系统故障时能够恢复。

Oracle RAC 运行于集群之上,为 Oracle 数据库提供了最高级别的可用性、可伸缩性和低成本计算能力。如果集群内的一个节点发生故障,Oracle 将可以继续在其余的节点上运行。Oracle 的主要创新是一项称为高速缓存合并的技术。高速缓存合并使得集群中的节点可以通过高速集群互联高效地同步其内存高速缓存,从而最大限度地低降低磁盘 I/O。高速缓存最重要的优势在于它能够使集群中所有节点的磁盘共享对所有数据的访问。数据无需在节点间进行分区。Oracle 是唯一提供具备这一能力的开放系统数据库的厂商。其它声称可以运行在集群上的数据库软件需要对数据库数据进行分区,显得不切实际。企业网格是未来的数据中心,构建于由标准化商用组件构成的大型配置之上,其中包括:处理器、网络和存储器。Oracle RAC 的高速缓存合并技术提供了最高等级的可用性和可伸缩性。Oracle 数据库 10g 和 OracleRAC 10g 显著降低了运营成本,增强了灵活性,从而赋予了系统更卓越的适应性、前瞻性和灵活性。动态提供节点、存储器、CPU 和内存可以在实现所需服务级别的同时,通过提高的利用率不断降低成本。

本博主配置好的Centos6 下 Oracle12C RAC 集群环境虚拟机文件下载,链接:https://pan.baidu.com/s/1_xF5m7rcAuPw5LAn6rrgyA
提取码:udai 下载后,用Vmware workstation打开,即可以正常使用

阅读更多

Centos6下MySQL5.6高可用方案-PXC集群环境虚拟机下载

本博主配置好的Centos6下MySQL5.6高可用方案-PXC集群环境虚拟机下载,链接:https://pan.baidu.com/s/1fuTXUNMpULlSHiriw2xKEg
提取码:3897 下载后,用Vmware workstation 打开即可以正常使用。

对于mysql高可用方案,经常用到的的主要有下面三种:

一、基于主从复制的高可用方案:双节点主从 + keepalived

一般来说,中小型规模的时候,采用这种架构是最省事的。
两个节点可以采用简单的一主一从模式,或者双主模式,并且放置于同一个VLAN中,在master节点发生故障后,利用keepalived/heartbeat的高可用机制实现快速
切换到slave节点。

在这个方案里,有几个需要注意的地方:
采用keepalived作为高可用方案时,两个节点最好都设置成BACKUP模式,避免因为意外情况下(比如脑裂)相互抢占导致往两个节点写入相同数据而引发冲突;
1)把两个节点的auto_increment_increment(自增步长)和auto_increment_offset(自增起始值)设成不同值。其目的是为了避免master节点意外宕机时,
可能会有部分binlog未能及时复制到slave上被应用,从而会导致slave新写入数据的自增值和原先master上冲突了,因此一开始就使其错开;当然了,如果有合适的
容错机制能解决主从自增ID冲突的话,也可以不这么做;
2)slave节点服务器配置不要太差,否则更容易导致复制延迟。作为热备节点的slave服务器,硬件配置不能低于master节点;
3)如果对延迟问题很敏感的话,可考虑使用MariaDB分支版本,或者直接上线MySQL 5.7最新版本,利用多线程复制的方式可以很大程度降低复制延迟;
4)对复制延迟特别敏感的另一个备选方案,是采用semi sync replication(就是所谓的半同步复制)或者后面会提到的PXC方案,基本上无延迟,不过事务并发性
能会有不小程度的损失,需要综合评估再决定;
5)keepalived的检测机制需要适当完善,不能仅仅只是检查mysqld进程是否存活,或者MySQL服务端口是否可通,还应该进一步做数据写入或者运算的探测,判断响
应时间,如果超过设定的阈值,就可以启动切换机制;
6)keepalived最终确定进行切换时,还需要判断slave的延迟程度。需要事先定好规则,以便决定在延迟情况下,采取直接切换或等待何种策略。直接切换可能因为复
制延迟有些数据无法查询到而重复写入;
7)keepalived或heartbeat自身都无法解决脑裂的问题,因此在进行服务异常判断时,可以调整判断脚本,通过对第三方节点补充检测来决定是否进行切换,可降低脑
裂问题产生的风险。

双节点主从+keepalived/heartbeat方案架构示意图见下:

二、基于主从复制的高可用方案:多节点主从+MHA/MMM

多节点主从,可以采用一主多从,或者双主多从的模式。
这种模式下,可以采用MHA或MMM来管理整个集群,目前MHA应用的最多,优先推荐MHA,最新的MHA也已支持MySQL 5.6的GTID模式了,是个好消息。

MHA的优势很明显:
1)开源,用Perl开发,代码结构清晰,二次开发容易;
2)方案成熟,故障切换时,MHA会做到较严格的判断,尽量减少数据丢失,保证数据一致性;
3)提供一个通用框架,可根据自己的情况做自定义开发,尤其是判断和切换操作步骤;
4)支持binlog server,可提高binlog传送效率,进一步减少数据丢失风险。

不过MHA也有些限制:
1)需要在各个节点间打通ssh信任,这对某些公司安全制度来说是个挑战,因为如果某个节点被黑客攻破的话,其他节点也会跟着遭殃;
2)自带提供的脚本还需要进一步补充完善,当然了,一般的使用还是够用的。

三、基于Galera协议的高可用方案:PXC
本博主配置好的Centos6下MySQL5.6高可用方案-PXC集群环境虚拟机下载,链接:https://pan.baidu.com/s/1fuTXUNMpULlSHiriw2xKEg
提取码:3897 下载后,用Vmware workstation 打开即可以正常使用

Galera是Codership提供的多主数据同步复制机制,可以实现多个节点间的数据同步复制以及读写,并且可保障数据库的服务高可用及数据一致性。
基于Galera的高可用方案主要有MariaDB Galera Cluster和Percona XtraDB Cluster(简称PXC),目前PXC用的会比较多一些。
mariadb的集群原理跟PXC一样,maridb-cluster其实就是PXC,两者原理是一样的。

下面重点介绍下基于PXC的mysql高可用环境部署记录。

1、PXC介绍

Percona XtraDB Cluster(简称PXC集群)提供了MySQL高可用的一种实现方法。
1)集群是有节点组成的,推荐配置至少3个节点,但是也可以运行在2个节点上。
2)每个节点都是普通的mysql/percona服务器,可以将现有的数据库服务器组成集群,反之,也可以将集群拆分成单独的服务器。
3)每个节点都包含完整的数据副本。

PXC集群主要由两部分组成:Percona Server with XtraDB和Write Set Replication patches(使用了Galera library,一个通用的用于事务型应用的同步、多主复制插件)。

2、PXC特性

1)同步复制,事务要么在所有节点提交或不提交。
2)多主复制,可以在任意节点进行写操作。
3)在从服务器上并行应用事件,真正意义上的并行复制。
4)节点自动配置,数据一致性,不再是异步复制。

PXC最大的优势:强一致性、无同步延迟

3、PXC优缺点

PXC的优点
1)服务高可用;
2)数据同步复制(并发复制),几乎无延迟;
3)多个可同时读写节点,可实现写扩展,不过最好事先进行分库分表,让各个节点分别写不同的表或者库,避免让galera解决数据冲突;
4)新节点可以自动部署,部署操作简单;
5)数据严格一致性,尤其适合电商类应用;
6)完全兼容MySQL;

虽然PXC有这么多好处,但也有些局限性:
1)只支持InnoDB引擎;当前版本(5.6.20)的复制只支持InnoDB引擎,其他存储引擎的更改不复制。然而,DDL(Data Definition Language) 语句在statement级别
被复制,并且,对mysql.*表的更改会基于此被复制。例如CREATE USER…语句会被复制,但是 INSERT INTO mysql.user…语句则不会。
(也可以通过wsrep_replicate_myisam参数开启myisam引擎的复制,但这是一个实验性的参数)。
2)PXC集群一致性控制机制,事有可能被终止,原因如下:集群允许在两个节点上同时执行操作同一行的两个事务,但是只有一个能执行成功,另一个会被终止,集群会给被终止的
客户端返回死锁错误(Error: 1213 SQLSTATE: 40001 (ER_LOCK_DEADLOCK)).
3)写入效率取决于节点中最弱的一台,因为PXC集群采用的是强一致性原则,一个更改操作在所有节点都成功才算执行成功。
4)所有表都要有主键;
5)不支持LOCK TABLE等显式锁操作;
6)锁冲突、死锁问题相对更多;
7)不支持XA;
8)集群吞吐量/性能取决于短板;
9)新加入节点采用SST时代价高;
10)存在写扩大问题;
11)如果并发事务量很大的话,建议采用InfiniBand网络,降低网络延迟;

事实上,采用PXC的主要目的是解决数据的一致性问题,高可用是顺带实现的。因为PXC存在写扩大以及短板效应,并发效率会有较大损失,类似semi sync replication机制。

本博主配置好的Centos6下MySQL5.6高可用方案-PXC集群环境虚拟机下载,链接:https://pan.baidu.com/s/1fuTXUNMpULlSHiriw2xKEg
提取码:3897 下载后,用Vmware workstation 打开即可以正常使用