0%

mysql数据备份

方案二:双主机HA部署

前提:准备两个机器master1(172.20.3.113)和master2(172.20.3.114),且分别安装了mysql,其中IP地址根据生产具体ip进行替换

一、配置my.cnf信息

  • 配置/etc/my.cnf文件(从mysql5.7开始不会自动生成my.cnf文件,所以需要手动创建)my.cnf文件内容大致如下:

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    [mysql]
    default-character-set=utf8 #设置mysql客户端默认字符集
    [mysqld]
    port = 3306 #可自行更改端口
    basedir=/usr/local/mysql
    datadir=/usr/local/mysql/data
    max_connections = 500 #最大连接数
    log_bin=mysql-bin
    server_id = 1 #机器1设置为1,机器2设置为2
    binlog_format=ROW
    auto-increment-increment = 2 #字段变化增量值
    auto-increment-offset = 1 #机器1设置为1,机器2设置为2
    slave-skip-errors = all #忽略所有复制产生的错误
    gtid_mode=ON
    enforce-gtid-consistency=ON

    character-set-server = utf8
    default-storage-engine = INNODB
    lower_case_table_names = 1
    • [mysql]代表我们使用mysql命令登录mysql数据库时的默认设置

    • [mysqld]代表数据库自身的默认设置

      注意:机器1和机器2只有server-id不同和auto-increment-offset不同,其他必须相同。

      部分配置项解释如下:

      binlog_format= ROW:指定mysql的binlog日志的格式,日志中会记录成每一行数据被修改的形式,然后在 slave 端再对相同的数据进行修改。

      auto-increment-increment= 2:表示自增长字段每次递增的量,其默认值是1。它的值应设为整个结构中服务器的总数,本案例用到两台服务器,所以值设为2。

      auto-increment-offset= 2:用来设定数据库中自动增长的起点(即初始值),因为这两能服务器都设定了一次自动增长值2,所以它们的起点必须得不同,这样才能避免两台服务器数据同步时出现主键冲突。

      注:另外还可以在my.cnf配置文件中,添加“binlog_do_db=数据库名”配置项(可以添加多个)来指定要同步的数据库。如果配置了这个配置项,如果没添加在该配置项后面的数据库,则binlog不记录它的事件。

  • 切换到datacanvas用户进行mysql启动服务 (建议)

    1
    /usr/local/mysql/support-files/mysql.server start

    或者在已经创建软连接的前提下,切换到root用户,并启动mysql服务

    1
    service mysql restart
  • 客户端登录

    1
    /usr/local/mysql/bin/mysql -uroot -p

    设置可远程登录root用户

    1
    2
    GRANT ALL PRIVILEGES ON *.* TO 'root'@'%' IDENTIFIED BY '123456' WITH GRANT OPTION;
    FLUSH PRIVILEGES;

    注意:上面的密码’123456’修改成真实的root密码

开始设置双主备份

  • 在master1上操作

    1
    2
    3
    4
    5
    6
    7
    8
    9
    先在master2上执行,
    show master status;(获取master_log_file和master_log_pos信息)

    在master1上执行
    change master to master_host='172.20.3.114',master_port=3306,master_user='rt',master_password='rt123',master_log_file='mysql-bin.000003',master_log_pos=194;

    start slave;

    show slave status\G
  • 在master2上操作

    1
    2
    3
    4
    5
    6
    7
    8
    先在master1上执行,
    show master status;(获取master_log_file和master_log_pos信息)
    在master2上执行
    change master to master_host='172.20.3.113',master_port=3306,master_user='rt',master_password='rt123',master_log_file='mysql-bin.000004',master_log_pos=194;

    start slave;

    show slave status\G

二、keepalived安装配置

需要在master1和master2的机器上安装keepalived服务,安装过程大致如下:

  • 通过地址https://pkgs.org/download/keepalived下载相应的安装版本,然后解压的相关目录。

  • 源码的安装一般由3个步骤组成:配置(configure)、编译(make)、安装( make install)

    1
    ./configure --prefix=/usr/local/keepalived

    如果提示错误信息

    1
    2
    3
    configure: error: 
    !!! OpenSSL is not properly installed on your system. !!!
    !!! Can not include OpenSSL headers files. !!!

    需要安装yum install openssl openssl-devel(RedHat系统),
    再次执行./configure –prefix=/usr/local/keepalived

  • 在安装目录执行make && make install进行编译安装

  • keepalived配置文件,默认情况下keepalived启动时会去/etc/keepalived目录下加载配置文件keepalived.conf

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
! Configuration File forkeepalived
global_defs {
notification_email {
[email protected]
}
notification_email_from [email protected]
smtp_server 127.0.0.1
smtp_connect_timeout 30
router_id MYSQL_HA #标识,双主相同
}
vrrp_instance VI_1 {
state BACKUP #两台都设置BACKUP
interface eth0 #网卡名称
virtual_router_id 51 #主备相同
priority 100 #优先级,另一台改为90
advert_int 1
nopreempt #不抢占,只在优先级高的机器上设置即可,优先级低的机器不设置
authentication {
auth_type PASS #鉴权,默认通过
auth_pass 1111 # 鉴权访问密码
}
virtual_ipaddress {
172.20.3.200 #虚拟ip
}
}

virtual_server 172.20.3.200 3306 {
delay_loop 2 #每个2秒检查一次real_server状态
lb_algo wrr #LVS算法
lb_kind DR #LVS模式
persistence_timeout 60 #会话保持时间
protocol TCP
real_server 172.20.3.113 3306 {
weight 1 #指定了当前主机的权重
notify_down /usr/local/keepalived/kill_keepalived.sh #检测到服务down后执行的脚本
TCP_CHECK {
connect_timeout 10 #连接超时时间
delay_before_retry 3 #重连间隔时间
connect_port 3306 #健康检查端口
}
}
real_server 172.20.3.114 3306 {
weight 2
notify_down /usr/local/keepalived/kill_keepalived.sh #检测到服务down后执行的脚本
TCP_CHECK {
connect_timeout 10
delay_before_retry 3
connect_port 3306
}
}
}

注意:参数priority两个服务器配置不同,其中virtual_ipaddress是虚拟ip,之后项目可通过访问 172.20.3.200:3306进行访问双主mysql机群。

上述配置中会涉及/usr/local/keepalived/kill_keepalived.sh,分别在两台服务器上编写kill_keepalived.sh脚本内容:

1
2
#!/bin/bash
pkill keepalived

然后给脚本加权限

1
chmod +x /usr/local/keepalived/kill_keepalived.sh
  • 启动keepalived服务
    1
    service keepalived start
    如果启动失败,尝试输入pkill -9 keepalived,然后再尝试重启

三、访问双主mysql集群

两台机器的mysql和keepalived配置完成之后,即可在项目中,通过访问虚拟ip地址(172.20.3.200:3306)进行mysql集群的访问。

mysql数据备份

方案一:定期备份数据库数据文件

一、编写shell脚本

脚本文件backup_mysql.sh信息如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
#用户名
username=root
#密码
password=填写密码
#将要备份的数据库
database_name=填写需要备份的数据库

#保存备份文件最多个数
count=30
#备份保存路径
backup_path=/data/mysql_backup
#日期
date_time=`date +%Y-%m-%d-%H-%M`

#如果文件夹不存在则创建
if [ ! -d $backup_path ];
then
mkdir -p $backup_path;
fi
#开始备份
mysqldump -u $username -p$password $database_name > $backup_path/$database_name-$date_time.sql
#开始压缩
cd $backup_path
tar -zcvf $database_name-$date_time.tar.gz $database_name-$date_time.sql
#删除源文件
rm -rf $backup_path/$database_name-$date_time.sql
#更新备份日志
echo "create $backup_path/$database_name-$date_time.tar.gz" >> $backup_path/dump.log

#找出需要删除的备份
delfile=`ls -l -crt $backup_path/*.tar.gz | awk '{print $9 }' | head -1`

#判断现在的备份数量是否大于阈值
number=`ls -l -crt $backup_path/*.tar.gz | awk '{print $9 }' | wc -l`

if [ $number -gt $count ]
then
#删除最早生成的备份,只保留count数量的备份
rm $delfile
#更新删除文件日志
echo "delete $delfile" >> $backup_path/dump.log
fi

该脚本实现的功能:备份指定数据库的数据信息到指定目录,并只保存指定数量的最新文件。

注意:脚本中需要补全脚本中的passworddatabase_name信息,可修改备份保存路径backup_path,以及最多保存的备份文件数量count

编写完脚本信息之后,需要给脚本赋予可执行权限 chmod +x backup_mysql.sh

二、设定定时任务crontab

运行crontab -e命令,打开一个可编辑的文本,输入0 1 * * * /path/to/backup_mysql.sh 保本并退出即添加完成。

注意:其中0 1 * * *,表示每天凌晨1点进行备份操作,可自行修改1的值(范围0~23)

其中路径信息/path/to/backup_mysql.sh需要修改为实际的脚本路径。

应用场景

风险控制
对用户异常行为模式进行实时检测,当一个用户发生了不该发生的行为,判定这个用户是不是有违规操作的嫌疑。

策略营销
用预先定义好的规则对用户的行为轨迹进行实时跟踪,对行为轨迹匹配预定义规则的用户实时发送相应策略的推广。

运维监控
灵活配置多指标、多依赖来实现更复杂的监控模式。

Watermark是Apache Flink为了处理EventTime 窗口计算提出的一种机制,本质上也是一种时间戳。

由Apache Flink Source或者自定义的Watermark生成器按照需求Punctuated或者Periodic两种方式生成的一种系统Event,与普通数据流Event一样流转到对应的下游算子,接收到Watermark Event的算子以此不断调整自己管理的EventTime clock。

Apache Flink 框架保证Watermark单调递增,算子接收到一个Watermark时候,框架知道不会再有任何小于该Watermark的时间戳的数据元素到来了,所以Watermark可以看做是告诉Apache Flink框架数据流已经处理到什么位置(时间维度)的方式。

Watermark的产生和Apache Flink内部处理逻辑如下图所示:

产生方式

  • Punctuated - 数据流中每一个递增的EventTime都会产生一个Watermark。 在实际的生产中Punctuated方式在TPS很高的场景下会产生大量的Watermark在一定程度上对下游算子造成压力,所以只有在实时性要求非常高的场景才会选择Punctuated的方式进行Watermark的生成。

  • Periodic - 周期性的(一定时间间隔或者达到一定的记录条数)产生一个Watermark。在实际的生产中Periodic的方式必须结合时间和积累条数两个维度继续周期性产生Watermark,否则在极端情况下会有很大的延时。

what ?

State是指流计算过程中计算节点的中间计算结果或元数据属性,比如 在aggregation过程中要在state中记录中间聚合结果,比如 Apache Kafka 作为数据源时候,我们也要记录已经读取记录的offset,这些State数据在计算过程中会进行持久化(插入或更新)。所以Apache Flink中的State就是与时间相关的,Apache Flink任务的内部数据(计算数据和元数据属性)的快照。

why ?

与批计算相比,State是流计算特有的,批计算没有failover机制,要么成功,要么重新计算。流计算在 大多数场景 下是增量计算,数据逐条处理(大多数场景),每次计算是在上一次计算结果之上进行处理的,这样的机制势必要将上一次的计算结果进行存储(生产模式要持久化),另外由于 机器,网络,脏数据等原因导致的程序错误,在重启job时候需要从成功的检查点(checkpoint,后面篇章会专门介绍)进行state的恢复。增量计算,Failover这些机制都需要state的支撑。

how ?

存储实现

  • 基于内存的HeapStateBackend - 在debug模式使用,不 建议在生产模式下应用;

  • 基于HDFS的FsStateBackend - 分布式文件持久化,每次读写都产生网络IO,整体性能不佳;

  • 基于RocksDB的RocksDBStateBackend - 本地文件+异步HDFS持久化;

    Apache Flink版本选择用RocksDB+HDFS的方式进行State的存储,State存储分两个阶段,首先本地存储到RocksDB,然后异步的同步到远程的HDFS。 这样而设计既消除了HeapStateBackend的局限(内存大小,机器坏掉丢失等),也减少了纯分布式存储的网络IO开销。

  • 还有一个是基于Niagara(Alibaba内部实现)NiagaraStateBackend - 分布式持久化- 在Alibaba生产环境应用;

分类

通过算子和数据层面划分

  • 算子类state

    KeyedState - 这里面的key是我们在SQL语句中对应的GroupBy/PartitioneBy里面的字段,key的值就是groupby/PartitionBy字段组成的Row的字节数组,每一个key都有一个属于自己的State,key与key之间的State是不可见的

  • 数据类state

    OperatorState - Apache Flink内部的Source Connector的实现中就会用OperatorState来记录source数据读取的offset。

checkpoint

checkpoint是使Flink 能从故障恢复的一种内部机制。检查点是 Flink 应用状态的一个一致性副本,包括了输入的读取位点。在发生故障时,Flink 通过从检查点加载应用程序状态来恢复,并从恢复的读取位点继续处理,就好像什么事情都没发生一样。Flink的状态存储在Flink的内部,这样做的好处就是不再依赖外部系统,降低了对外部系统的依赖,在Flink的内部,通过自身的进程去访问状态变量.同时会定期的做checkpoint持久化,把checkpoint存储在一个分布式的持久化系统中,如果发生故障,就会从最近的一次checkpoint中将整个流的状态进行恢复.

MemoryStateBackend

1 基于内存的状态管理器,聚合类算子的状态会存储在JobManager的内存中

2 单次状态大小默认最大被限制为5MB,可以通过构造函数来指定状态初始化内存大小。无论单次状态大小最大被限制为多少,都不可大于akka的frame大小(1.5MB,JobManager和TaskManager之间传输数据的最大消息容量)。状态的总大小不能超过 JobManager 的内存。

3 是Flink默认的后端状态管理器,默认是异步的

4 主机内存中的数据可能会丢失,任务可能无法恢复

5 将工作state保存在TaskManager的内存中,并将checkpoint数据存储在JobManager的内存中

适用:本地开发和调试、状态比较少的作业

FsStateBackend

1 基于文件系统的状态管理器(这里的文件系统可以是本地共享文件系统,也可以是hdfs分布式文件系统。)

2 如果使用,默认是异步

3 比较稳定,3个副本,比较安全。不会出现任务无法恢复等问题

4 状态大小受磁盘容量限制

5 将工作state保存在TaskManager的内存中,并将checkpoint数据存储在文件系统中

适用:状态比较大,窗口比较长,大的KV状态

RocksDBStateBackend

  1. RocksDBStateBackend 采用异步的方式进行状态数据的 Snapshot, 任务中的状态数据首先被写人 RocksDB 中,然后再异步地将状态数据写人文件系统中,这样在rocksDB中仅会存储正在进行计算的热数据,对于长时间才更新的数据则写人磁盘中进行存储。而对于体量比较小的元数据状态,则直接存储在 JobManager 的内存中。

  2. 与 FsStateBackend 相比,RocksDBState Backend 在性能上要比 FsStateBackend 高一些,主要是因为借助于 RocksDB 存储了最新热数据,然后通过异步的方式再同步到文件系统中,但 RocksDBState Backend 和 Memory State Backend 相比性能就会较弱一些。

  3. 需要注意的是ROCksDB通过JNI的方式进行数据的交互,而JNI构建在byte[]数据结构之上,因此每次能够传输的最大数据量为2^31字节,也就是说每次在RocksDBState Backend 合并的状态数据量大小不能超过 2^31 字节限制,否则将会导致状态数据无法同步,这是RocksDB 采用JNI 方式的限制,用户在使用过程中应当注意。

综上可以看出,RocksDBState Backend 和 FsState Backend 一样,适合于任务状态数据非常大的场景。在Flink 最新版本中,已经提供了基于 RocksDBState Backend 实现的增量 Checkpoints 功能,极大地提高了状态数据同步到介质中的效率和性能,在后续的社区发展中,RocksDBStateBackend 也会作为状态管理器重点使用的方式之一。

流式数仓(Streaming Warehouse)更准确地说,其实是“make data warehouse streaming”,就是让整个数仓的数据全实时地流动起来,且是以纯流的方式而不是微批(mini-batch)的方式流动。

目标是实现一个具备端到端实时性的纯流服务(Streaming Service),用一套 API 分析所有流动中的数据,当源头数据发生变化,比如捕捉到在线服务的 Log 或数据库的 Binlog 以后,就按照提前定义好的 Query 逻辑或数据处理逻辑,对数据进行分析,分析后的数据落到数仓的某一个分层,再从第一个分层向下一个分层流动,然后数仓所有分层会全部流动起来,最终流到一个在线系统里,用户可以看到整个数仓的全实时流动效果。

在这个过程中,数据是主动的,而查询是被动的,分析由数据的变化来驱动。同时在垂直方向上,对每一个数据明细层,用户都可以执行 Query 进行主动查询,并且能实时获得查询结果。此外,它还能兼容离线分析场景,API 依然是同一套,实现真正的一体化。

  • 解压带有中文名称的zip包
1
ditto -V -x -k --sequesterRsrc filename.zip destination
  • 查看目录下文件夹大小
    1
    2
    3
    du -d 1 -h    命令查看当前目录下所有文件夹的大小 -d 指深度,后面加一个数值

    du -hd1

文件系统

fileSystemType.jpeg

  • Mac 默认可以读 Windows 的 NTFS 格式,但不能写。

  • Windows 无法识别 Mac 的 HFS+ 或 APFS 格式。

  • Mac 和 Windows 都能正常读写 FAT32 和 ExFAT 格式

  • linux

    1
    2
    3
    4
    5
    6
    7
    8
    9
    Linux:存在几十个文件系统类型:ext2,ext3,ext4,xfs,brtfs,zfs(man 5 fs可以取得全部文件系统的介绍)

    不同文件系统采用不同的方法来管理磁盘空间,各有优劣;文件系统是具体到分区的,所以格式化针对的是分区,分区格式化是指采用指定的文件系统类型对分区空间进行登记、索引并建立相应的管理表格的过程。

    ext2具有极快的速度和极小的CPU占用率,可用于硬盘和移动存储设备
    ext3增加日志功能,可回溯追踪
    ext4日志式文件系统,支持1EB(1024*1024TB),最大单文件16TB,支持连续写入可减少文件碎片。rhel6默认文件系统
    xfs可以管理500T的硬盘。rhel7默认文件系统
    brtfs文件系统针对固态盘做优化,
  • windows

    1
    2
    3
    FAT16:MS—DOS和win95采用的磁盘分区格式,采用16位的文件分配表,只支持2GB的磁盘分区,最大单文件2GB,且磁盘利用率低
    FAT32:(即Vfat)采用32位的文件分配表,支持最大分区128GB,最大文件4GB
    NTFS:支持最大分区2TB,最大文件2TB,安全性和稳定性非常好,不易出现文件碎片。

reference

https://www.yinxiang.com/everhub/note/0312ed71-61f5-4c75-9c77-3db0ffdeb613