Relay

基于Docker的Mysql主从复制搭建 为什么基于Docker搭建？ 资源有限 虚拟机搭建对机器配置有要求，并且安装mysql步骤繁琐 一台机器上可以运行多个Docker容器 Docker容器之间相互独立，有独立ip，互不冲突 Docker使用步骤简便，启动容器在秒级别 利用Docker搭建主从服务器 首先拉取docker镜像,我们这里使用5.7版本的mysql： docker pull mysql: 5.7 然后使用此镜像启动容器，这里需要分别启动主从两个容器 Master(主)： docker run -p 3339:3306 --name mysql-master -e MYSQL_ROOT_PASSWORD=123456 -d mysql:5.7 Slave(从)： docker run -p 3340 : 3306 --name mysql-slave -e MYSQL_ROOT_PASSWORD= 123456 -d mysql: 5.7 Master对外映射的端口是3339，Slave对外映射的端口是3340。因为docker容器是相互独立的，每个容器有其独立的ip，所以不同容器使用相同的端口并不会冲突。这里我们应该尽量使用mysql默认的3306端口，否则可能会出现无法通过ip连接docker容器内mysql的问题。 使用 docker ps -a

一. 概述 　　在上一篇中，搭建了一主一从的复制架构，这篇通过一些诊断方法来了解复制的运行状态和一些选项参数说明。上次mysql主从服务关机,今天在打开mysql服务，出现了错误信息。 　　 1. 首先 启动主从 mysql 服务 　　2. 在从库上执行 START SLAVE ， 开始复制。 　　3. 在从库上执行 SHOW PROCESSLIST; slave 已经连接上 master, 并开始接受并执行日志。 　　 4.在从库上执行SHOW SLAVE STATUS，查看复制状态 　　　　错误信息: Got fatal error 1236 from master when reading data from binary log: 'Could not find first log file name in binary log index file' 　　5. 解决方法　 -- 在主库上执行,记录日志文件号和位置，如下图所示： flush logs; show master status; -- 在从库上执行 CHANGE MASTER TO MASTER_LOG_FILE = ' mysql-bin.000072 ' ,MASTER_LOG_POS = 154 ; SLAVE START; 　　　　从库上再执行SHOW PROCESSLIST，显示了二个复制进程：一个是

测试环境： 主节点：81.69.247.195 从节点：124.71.182.20 linux：centos6.5 主: 1. 编辑 vim /etc/my.cnf 添加：log-bin = mysql-bin 添加 :server-id =1 添加：innodb-file-per-table =ON 添加：skip_name_resolve=ON 2. 重启mysql：service mysqld restart 3.进入mysql：mysql -u root -p 4.查看二进制信息： show global variables like '%log%'; 5.查看主节点二进制日志列表 show master logs; 6.查看主节点的server id show global variables like '%server%'; 7.在主节点上创建有复制权限的用户。REPLIACTION SLAVE ，REOPLIATION CLIENT grant replication slave,replication client on *.* to 'admin'@'124.71.182.20' identified by '123456'; 8.刷新 flush privileges; 从： 1. 编辑 vim /etc/my.cnf 添加：relay-log=relay

Gtid基本概念: 传统的基于binlog position复制的方式有个严重的缺点：如果slave连接master时指定的binlog文件错误或者position错误，会造成遗漏或者重复，很多时候前后数据是有依赖性的，这样就会出错而导致数据不一致。 从MYSQL5.6开始，mysql开始支持GTID复制。GTID的全称是global transaction id，表示的是全局事务ID。GTID的分配方式为uuid:trans_id，其中： uuid是每个mysql服务器都唯一的，记录在$datadir/auto.cnf中。如果复制结构中，任意两台服务器uuid重复的话(比如直接冷备份时，auto.conf中的内容是一致的)，在启动复制功能的时候会报错。这时可以删除auto.conf文件再重启mysqld。 Gtid的作用: Gtid,采用了新的复制协议，旧协议是，首先从服务器上在一个特定的偏移量位置连接到主服务器上一个给定的二进制日志文件,然后主服务器再从给定的连接点开始发送所有的事件。 新协议有所不同，支持以全局统一事务ID(GTID)为基础的复制。当在主库上提交事务或者被从库应用时，可以定位和追踪每一个事务。GTID复制是全部以事务为基础，使得检查主从一致性变得非常简单。如果所有主库上提交的事务也同样提交到从库上，一致性就得到了保证。 Gtid复制的好处： 1

MySQL 5.7.18的安装与主从复制 IP 计算机名 角色 192.168.1.222 001 master 192.168.1.233 002 slave CentOS 6.9安装mysql5.7.18 # 这里只展示一台的安装过程，另一台一样操作 下载地址：https://dev.mysql.com/get/Downloads/MySQL-5.7/mysql-5.7.18-linux-glibc2.5-x86_64.tar.gz 1、下载，解压，并创建软链接 [root@001 ~]# wget https://dev.mysql.com/get/Downloads/MySQL-5.7/mysql-5.7.18-linux-glibc2.5-x86_64.tar.gz [root@001 ~]# tar xf mysql-5.7.18-linux-glibc2.5-x86_64.tar.gz -C /usr/local/ [root@001 ~]# cd /usr/local/ [root@001 local]# ln -sv mysql-5.7.18-linux-glibc2.5-x86_64/ mysql 2、新建mysql用户组和mysql用户 [root@001 local]# groupadd mysql [root@001 local]# useradd -g

一）camke源码编译安装mysql 1）创建软件安装目录software 1 [root@master software]# ls 2 cmake-2.8.8.tar.gz mysql-5.5.32 .tar.gz 3 [root@master software]# 2)解压cmak软件 1 [root@master software]# tar xf cmake-2.8.8 .tar.gz 2 [root@master software]# ls 3 cmake-2.8.8 cmake-2.8.8.tar.gz mysql-5.5.32 .tar.gz 4 [root@master software]# cd cmake-2.8.8/ 3)在cmake目录下编译 1 [root@master software]# ./ configure 2 [root@master software]# gmake 3 [root@master software]# gmake install 4 [root@master software]# cd../ 4)安装依赖包 1 [root@master software]# yum install ncurses-devel -y 5)创建mysql组，并创建mysql用户指定mysql组且不能登录 1 [root@master

Nmap 7.30 ( https://nmap.org ) 使用方法: nmap [扫描类型(s)] [选项] {目标说明} 目标说明: 通过主机名称, IP 地址, 网段, 等等. 协议: scanme.nmap.org, microsoft.com/24, 192.168.0.1; 10.0.0-255.1-254 -iL <inputfilename>: 输入 主机或者网段 -iR <主机数>:随机选择目标 –exclude <主机1[,主机2][,主机3],…>: 排除的IP或者网段 –excludefile <exclude_file>: 从文件中排除 主机发现: -sL: List Scan – 简单的列出目标进行扫描 -sn: Ping Scan – 禁用端口扫描 -Pn: Treat all hosts as online — 不使用主机发现 -PS/PA/PU/PY[portlist]: 通过TCP SYN/ACK, UDP or SCTP 等协议发现指定端口 -PE/PP/PM: 使用ICMP协议响应, 时间戳, 和子网掩码 请求 发现 探测 -PO[protocol list]: 使用ip协议 -n/-R: Never do DNS resolution/Always resolve [默认选项] –dns-servers <serv1[,serv2],…>

网络层提供的两种服务 网络层关注的是如何将分组从源端沿着网络路径送达目的端。 在计算机网络领域，网络层应该向运输层提供怎样的服务（“面向连接”还是“无连接”）曾引起了长期的争论。 争论焦点的实质就是：在计算机通信中，可靠交付应当由谁来负责？是网络还是端系统？ 电信网：虚电路服务 ​ 虚电路表示这只是一条逻辑上的连接，分组都沿着这条逻辑连接按照存储转发方式传送，而并不真正建立了一条物理连接。 ​ 请注意，电路交换的电话通信是先建立了一条真正的连接。因此分组交换的虚连接和电路交换的连接只是类似，但并不完全一样。 因特网：数据报服务 网络层向只提供 简单灵活的 、 无连接的 、 尽最大努力交付的 数据报服务 网络在发送分组时不需要先建立连接。每一个分组（即 IP 数据报）独立发送，与其前后的分组无关（不进行编号）。 网络层不提供服务质量的承诺。即所传送的分组可能出错、丢失、重复和失序(不按序到达终点)，当然也不保证分组传送的时限。 尽最大努力交付的好处： 由于传输网络不提供端到端的可靠传输服务，这就使网络中的路由器可以做得比较简单，而且价格低廉(与电信网的交换机相比较)。 如果主机（即端系统）中的进程之间的通信需要是可靠的，那么就由网络的主机中的运输层负责（包括差错处理、流量控制等）。 采用这种设计思路的好处是:网络的造价大大降低，运行方式灵活，能够适应多种应用。

2020年HackingDay即将拉开了帷幕 还记得2019年的DackingDay吗？ 我们在广州，在杭州进行了狂欢技术趴 你是否get到了最精彩的亮点？ 表姐带你回顾2019！ 雷神众测 Hackingday Hackingday是雷神众测面向白帽免费开放的技术沙龙，专注于安全技术的交流及分享，助力提升白帽的安全专业技能，拓展漏洞挖掘新思路。 正如“知识应该被分享，安全更需携手共进 ” ，比起闭门造车，雷神众测更愿意把经验分享给各位白帽一起交流进步。 2019 活动历程 9.7 • HackingDay 2019 杭州站 • 会议议题： 1. 黑客与精酿 2. 代码审计点线面实战 3. Java反序列化漏洞自动挖掘方法 4. 红队行动之鱼叉攻击SMTP Relay 11.30 • HackingDay 2019 广州站 • 会议议题： 1. 供应链攻击 2. 域渗透中的DPAPI和Kerberos协议 3. 安全江湖之侠客行 4. 黑客与精酿 攻防对抗，跨界交流 会议议题 （详细ppt资料请关注公众号，回复“2019“获取） 代码审计点线面实战 阿里云·高级安全专家—jkgh006 工程化的人工审计是未来几年的趋势，代码审计的分解和实战成为安全工作者必须掌握的一种能力，从安全代码审计、框架流程分析、三方应用笔记和接口滥用要记这四个方面分享了代码审计研究方向

##MySQL GTID 系列之一 ###一.GTID相关概念 ####GTID:全局事务标识符,MySQL5.6版本开始在主从复制中推出的重量级特性。 ####每提交一个事务,当前执行线程都会拿到一个给定复制环境中唯一的GTID， ####GTID的格式如下: GTID = source_id:sequence_id sourceid:主服务器的唯一标识,通常用server_uuid来表示。 sequence_id:事务提交时由系统顺序分配的序列号,在Binlog中是递增且连续有序。 show master status \G ####1.1 GTID生命周期 #####1.MASTER产生GTID,保存到Binlog中。 #####2.发送Binlog到SLAVE,保存到Relay Log #####3.SQL线程从Relay Log中获取GTID,并设置为gtid_next,然后对比SLAVE端的Binlog是否有记录。 #####4.如果有记录，说明该GTID的事务已经执行，SLAVE会忽略。 #####5.如果没有记录，SLAVE就会从Relay Log中执行该GTID的事务，并记录到Binlog。 #####6.SLAVE不生成GTID ####1.2 GTID的优点 #####1.一个事务对应一个唯一ID，一个GTID在一个服务器上只会执行一次 #####2