黑帽联盟

 找回密码
 会员注册
查看: 2762|回复: 2
打印 上一主题 下一主题

[集群服务] 两台服务器该如何有效利用

[复制链接]

895

主题

38

听众

3329

积分

管理员

Rank: 9Rank: 9Rank: 9

  • TA的每日心情
    难过
    昨天 22:31
  • 签到天数: 1652 天

    [LV.Master]伴坛终老

    之前自己写的,并测试过了。当然有不足的地方,欢迎指正。


    1. 服务器两台   centos-1(192.168.1.106)   centos-2(192.168.1.109)

    2. 需求:在centos-1服务器上搭建nginx和php环境,并且程序也放在此服务器上;另一台服务器搭建mysql环境
       考虑:服务器安全性,高可用性(成本的最大化利用)、稳定性


    ----------


    这里主要讲一下高可用性和安全性
    高可用
    1. 高可用性:
    主要针对centos-2这台服务器,因为这台服务器只提供一个mysql服务,其他系统资源不能被充分的被利用,导致系统资源浪费
    2. 可利用centos-2服务器做数据库备份

    安全性
    1. centos-1前端服务器,INPUT和OUTPUT链上的策略默认为DROP,指定打开某些常用的服务和端口。如:web服务:80、ssh:22、ftp服务:21,20
        ssh防爆力破解
    2. centos-2服务器,即数据库服务器,INPUT和OUTPUT链上的策略也默认为DROP,对外,也只开启mysql服务和ssh服务


    ----------


    在两台服务器上搭建相应的环境:
    centos-1 nginx+php
    centos-2 mysql
    具体环境搭建方法就不详细介绍了


    ----------


    设置防火墙规则以保证服务器的安全性
    1. centos-1上的防火墙规则:(这里就不隐藏了)

    Chain INPUT (policy DROP)
    target     prot opt source               destination         
    ACCEPT     tcp  --  0.0.0.0/0            192.168.1.106       state RELATED,ESTABLISHED
    DROP       tcp  --  0.0.0.0/0            192.168.1.106       tcp dpt:242 #conn/32 > 3
               tcp  --  0.0.0.0/0            192.168.1.106       tcp dpt:242 state NEW recent: SET name: SSH side: source
    DROP       tcp  --  0.0.0.0/0            192.168.1.106       tcp dpt:242 state NEW recent: UPDATE seconds: 300 hit_count: 3 name: SSH side: source
    ACCEPT     tcp  --  0.0.0.0/0            192.168.1.106       multiport dports 80,242,21 state NEW
    ACCEPT     tcp  --  192.168.1.109        192.168.1.106       tcp spt:3306 state NEW
    ACCEPT     tcp  --  0.0.0.0/0            192.168.1.106       tcp spt:80
    ACCEPT     udp  --  0.0.0.0/0            192.168.1.106       udp spt:53
    ACCEPT     icmp --  0.0.0.0/0            192.168.1.106       icmp type 8 state NEW,ESTABLISHED
    ACCEPT     all  --  127.0.0.1            127.0.0.1           

    Chain FORWARD (policy ACCEPT)
    target     prot opt source               destination         

    Chain OUTPUT (policy DROP)
    target     prot opt source               destination         
    ACCEPT     all  --  192.168.1.106        0.0.0.0/0           state RELATED,ESTABLISHED
    ACCEPT     tcp  --  192.168.1.106        0.0.0.0/0           tcp dpt:80
    ACCEPT     udp  --  192.168.1.106        0.0.0.0/0           udp dpt:53
    ACCEPT     tcp  --  192.168.1.106        192.168.1.109       tcp dpt:3306
    ACCEPT     all  --  127.0.0.1            127.0.0.1


    2. centos-2上的防火墙规则:

    Chain INPUT (policy DROP)
    target     prot opt source               destination         
    ACCEPT     tcp  --  0.0.0.0/0            192.168.1.109       state RELATED,ESTABLISHED
    ACCEPT     tcp  --  0.0.0.0/0            192.168.1.109       multiport dports 22,3306 state NEW

    Chain FORWARD (policy ACCEPT)
    target     prot opt source               destination         

    Chain OUTPUT (policy DROP)
    target     prot opt source               destination         
    ACCEPT     all  --  192.168.1.109        0.0.0.0/0           state RELATED,ESTABLISHED
    ACCEPT     tcp  --  192.168.1.109        192.168.1.106       tcp spt:3306



    ----------


    centos-2数据库自动备份,要求实时备份
    备份方式:
    1. 直接备份相应的数据库
        mysqldump -uroot -p 数据库名称 > 备份的路径/数据库名称.sql  (输入root密码即可)
       恢复相应的数据库
        mysql -uroot -p 数据库名称 < 备份的路径/数据库名称.sql  (输入root密码即可)
        *注意:这里的“数据库名称”在数据库里面必须要存在,不然恢复不成功,报错;如果不存在,在数据库里新建一个同名的数据库即可,然后再恢复*
    2. 备份全数据库+启用二进制日志记录功能(增量备份和数据恢复)
        小量的数据库可以每天进行完整备份,因为这也用不了多少时间,但当数据库很大时,就不太可能每天进行一次完整备份了,这时候就可以使用增量备份。增量备份的原理就是使用了mysql的binlog日志。
    本次操作的MySQL版本为5.5.40 for Linux (x86_64)。

    增量备份要确保打开了二进制日志,参考mysql的日志系统:

    mysql> show variables like '%log_bin%';
    首先对pak数据库做一个完整备份:

    没有启动日志记录功能的话,修改配置文件,把log-bin打开即可,最后重启服务
    EXPIRE_LOGS_DAYS
    此参数是设置日志的过期天数,过期的日志将会被自动删除,这有利于减少我们管理日志的工作量,需要修改my.cnf
    EXPIRE_LOGS_DAYS=3
    这里我们设定保存日志为3天,3天之后过期的日志将被自动删除

    $ mysqldump -h localhost -upak -ppwd -P3306 --master-data=2 --single-transaction --opt pak > pak_bak_full.sql
    这时候就会得到一个全备文件pak_bak_full.sql。mysqldump操作会导致滚动一次log,假设新的binlog文件是mysql-bin.000002。

    模拟插入数据和误操作

    a. 在pak库的某个表插入一些数据,然后执行flush logs命令。这时将会产生一个新的二进制日志文件mysql-bin.000003,mysql-bin.000002则保存了全备过后的所有更改,既增加记录的操作也保存在了mysql-bin.00002中。

    b. 再在pak库中的t_user表中增加两条记录,然后误删除t_user表。t_user中增加记录的操作和删除表的操作都记录在mysql-bin.000003中。

    开始恢复

    恢复过程不要记录日志:

    mysql > set global sql_log_bin=0;
    首先导入全备数据

    $ mysql -h localhost -upak -ppwd < pak_bak_full.sql

    mysql> source /path/backup/pak_bak_full.sql
    我们也可以看到全备时的binlog位置:

    head -50 backup-file.sql |grep 'CHANGE MASTER'
    -- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=4321;
    查看当前所在二进制日志中的位置:

    mysql> show master status;
    根据上面两个position能大概确定需要完整恢复哪几个binlog文件。

    恢复mysql-bin.000002
    在待恢复的position或时间点以前、全备以后的binlog需要全部恢复,多个文件以空格隔开

    $ mysqlbinlog /var/lib/mysql/mysql-bin.000002 | mysql -uroot -p
    此时查询可以得到前两条数据。

    恢复部分mysql-bin.000003
    这个日志中包括了新增记录和误删表两个部分,我们需要恢复到新增记录之后、误删操作以前的位置。

    如果知道误操作的命令如DROP TABLE,则可以通过下面的方法在binlog文件中找到误操作之前的那个position:
    (如下面的信息显示,误操作DROP TABLE之前的pos是775,在datetime 141204 15:08:04或pos 882时完成DROP TABLE操作)

    $ mysqlbinlog /var/lib/mysql/mysql-bin.000003 |grep -C 5 'DROP TABLE'
    #141204 15:07:05 server id 1  end_log_pos 775   Xid = 376
    COMMIT/*!*/;
    # at 775
    #141204 15:08:04 server id 1  end_log_pos 882   Query   thread_id=10    exec_time=0 error_code=0
    SET TIMESTAMP=1417676884/*!*/;
    DROP TABLE `t_user` /* generated by server */
    /*!*/;
    # at 882
    恢复命令:

    $ mysqlbinlog /var/lib/mysql/mysql-bin.000003 --stop-position=775 | mysql -h localhost -uroot -p
    如果position难以确定,但知道需要恢复到的确切(服务器)时间,也可以使用datetime:

    $ mysqlbinlog /var/lib/mysql/mysql-bin.000003 --stop-datetime="2014-12-04 15:08:00" | mysql -uroot -p
    如果不是误操作导致的,而是迁移数据库,那么不需要position或datetime,使用所有binlog文件增量恢复即可。

    确定恢复成功后记得打开日志记录:

    mysql > set global sql_log_bin=1;
    报错
    1. unknown variable 'default-character-set=utf8'
    在使用mysqlbinlog查看二进制日志的时候,提示下面的错误:

    /usr/local/mysql/bin/mysqlbinlog: unknown variable 'default-character-set=utf8'
    原因是在我为了统一mysql客户端到服务端的的字符编码,在/etc/my.cnf文件的[client]、[mysqld]等节加入了default-character-set = utf8,mysqlbinlog会从my.cnf中的[client]读取配置,但奈何mysqlbinlog并不认识这个选项(据说是个bug)导致的。

    应对这个bug的方法有两个:
    第一,自然是注释到[client]中的这个字符集配置;
    第二,改用loose-default-character-set = utf8。在选项前加了loose-,表示当程序不认识此选项时会略过此选项,并给出一个警告。



    ----------


    测试
    省略...


    黑帽联盟定位撰写





    帖子永久地址: 

    黑帽联盟 - 论坛版权1、本主题所有言论和图片纯属会员个人意见,与本论坛立场无关
    2、本站所有主题由该帖子作者发表,该帖子作者与黑帽联盟享有帖子相关版权
    3、其他单位或个人使用、转载或引用本文时必须同时征得该帖子作者和黑帽联盟的同意
    4、帖子作者须承担一切因本文发表而直接或间接导致的民事或刑事法律责任
    5、本帖部分内容转载自其它媒体,但并不代表本站赞同其观点和对其真实性负责
    6、如本帖侵犯到任何版权问题,请立即告知本站,本站将及时予与删除并致以最深的歉意
    7、黑帽联盟管理员和版主有权不事先通知发贴者而删除本文

    0

    主题

    0

    听众

    89

    积分

    黑帽新手

    Rank: 2

  • TA的每日心情
    开心
    2019-4-7 15:07
  • 签到天数: 62 天

    [LV.6]常住居民II

    回复

    使用道具 举报

    52

    主题

    2

    听众

    310

    积分

    黑帽学员

    Rank: 3Rank: 3

  • TA的每日心情
    奋斗
    2019-9-27 16:27
  • 签到天数: 258 天

    [LV.8]以坛为家I

    好文,这个我知道是定位写的,之前写过。原创支持
    回复

    使用道具 举报

    您需要登录后才可以回帖 登录 | 会员注册

    发布主题 !fastreply! 收藏帖子 返回列表 搜索
    回顶部