一、实验内容：
2、 使用客户端工具备份还原数据库
3、 使用日志文件恢复数据库
二、实验项目：学生成绩数据库
创建用于学生成绩管理数据库，数据库名为XSCJ中，XSCJ数据库中包括三个表：xs(学生基本情况表)、kc(课程信息表)、xs_cj(成绩表)。。
三、实验步骤：(要求使用语句完成)
1、 使用select into ……outfile导出xs表数据，导出文件名为xs.txt，要求每行记录结束回车换行；
81e797c2c6b2bf39e8224ee671ce647e.png
2、 使用create table like语句创建一个与xs表结构相同的表xs1，并使用load data将xs.txt的数据完整的导入xs1表中，并查看xs1表；
ca530d320003432441251d6e51809ff6.png
3、 使用select into ……outfile导出kc表数据，导出文件名为kc1.txt，要求字段之间用逗号隔开，字符型字段值用双引号括起来，每行记录以“->”开头，每行结束回车换行；
da32788bbec152b932b960b76d9c008d.png
4、 使用create table like语句创建一个与kc表结构相同的表kc1，并使用load data将kc1.txt的数据导入kc1表中，要求导入数据是忽略前面3条记录，只导入课程名、课程号、学分三列的数据；
ffd68720a4ed8428b61cd6d1d65bcd02.png
5、 使用mysqldump备份xscj数据库中的xs表到文件xs2.sql中；
9c7c64de9fa61ec43e5ac175e6945d7d.png
6、 使用mysqldump备份xscj数据库到文件xscj1.sql中
0e5ace5913933fbf7c12a53f0bc99875.png
7、 使用mysqldump备份xscj数据库和mysql数据库到文件twodatabase.sql中；
380c089e0891b90861dacff3b50e7be8.png
8、 使用mysqldump备份MySQL服务器中的所有数据库到文件all.sql中；
a0b9d6cef91a0ad5c98985ff6b002a76.png
9、 删除xs表，使用mysql命令将文件xs2.sql中的数据恢复到xscj数据库中
fb9e600c30fd5809d45a84af98830ba5.png
10、删除xscj数据库中的所有表，使用mysql命令将文件xscj1.sql中的数据恢复到xscj数据库中；
1d044046eb1957607aefe19f014f5c0c.png
11、将xs表中的数据清空，使用mysqlimport命令将xs.txt中的数据导入到xs表中。
9a000f99f8226008a6c1c8fc945f2a42.png
四、实验报告要求
1、 实验报告格式要求
包括内容：标题、实验内容、实验步骤、实验中遇到的问题及解决方案
2、 实验报告内容要求
(1) 标题参看实验指导标题+“实验报告”，如“实验一 MySQL的安装与命令初步实验报告”；
(2) 实验内容与实验指导中相同；
(3) 实验步骤中将自己实验中的每个步骤的命令和 *** 作结果显示界面进行截图完善。
(4) 实验中遇到的问题及解决方案中如实地将自己的问题的解决过程记录出来。
3、 实验报告提交要求
每次实验课结束之后，每个人需要提交实验报告，实验报告命名为：学号姓名
使用keepalived做mysql主从切换的高可用
keepalived切换的优缺点
1.可以切换虚拟IP
2.可能发生裂脑，就是主从服务器都同时出现一样的VIP，导致写入数据的时候，往主从都写入了数据
3.可能导致主从mysql数据不一致。主在down机的时候，有部分数据还没同步到从mysql
此实验在mysql使用gtid同步实现的前提下的
192.168.209.132 master
192.168.209.131 slave
1.安装keepalived
直接yum安装或者编译安装都可以，生产环境也是ok的
2.配置keepalived的配置文件
keepalived配置文件默认放在/etc/keepalived/文件夹下
如果不把配置文件放这里，那么启动keepalived的时候，需要用参数指定配置文件的位置
这里我用默认安装和默认配置文件位置
192.168.209.132:
vim /etc/keepalived/keepalived.conf
! Configuration File for keepalived
global_defs {
notification_email {
}
router_id SLAVE
}
vrrp_script chk_mysql {
script "/data/script/mysql_check.sh"
interval 2
weight -20
}
vrrp_instance VI_1 {
state BACKUP
interface eth0
nopreempt
virtual_router_id 131
priority 100
advert_int 1
authentication {
auth_type PASS
auth_pass 1111
}
virtual_ipaddress {
192.168.209.16
}
track_script {
chk_mysql
}
}
监控脚本：
vim /data/script/mysql_check.sh
#!/bin/sh
mysqlstr=/usr/local/mysql/bin/mysql
host=localhost
user=root
password=123456
port=33061
mysql_status=1
$mysqlstr -h $host -u $user -p$password -P $port -e "show status" >/dev/null 2>&1
if [ $? = 0 ] then
echo "mysql_status=1"
exit 0
else
pkill keepalived
fi
192.168.209.131:
vim /etc/keepalived/keepalived.conf
! Configuration File for keepalived
global_defs {
notification_email {
}
router_id SLAVE
}
vrrp_script chk_mysql {
script "/data/script/mysql_check.sh"
interval 2
weight -20
}
vrrp_instance VI_1 {
state BACKUP
interface eth0
nopreempt
virtual_router_id 131
priority 90
advert_int 1
authentication {
auth_type PASS
auth_pass 1111
}
virtual_ipaddress {
192.168.209.16
}
track_script {
chk_mysql
}
}
配置文件：
vim /data/script/mysql_check.sh
#!/bin/sh
mysqlstr=/usr/local/mysql/bin/mysql
host=localhost
user=root
password=123456
port=33061
mysql_status=1
$mysqlstr -h $host -u $user -p$password -P $port -e "show status" >/dev/null 2>&1
if [ $? = 0 ] then
echo "mysql_status=1"
exit 0
else
pkill keepalived
fi
对实验结果开始进行验证
192.168.209.132上获取到vip
把192.168.209.132上的mysqld给干掉
查看192.168.209.132上的mysqld和keepalived进程是否都被干掉了；虚拟IP是否切换到192.168.209.131上了
查看192.168.209.131上是否有VIP
把192.168.209.132上的keepalived和mysqld都启动起来。先启mysqld再起keepalived
此时keepalived启动起来了，虽然权重比192.168.209.131的高，但是设置了不抢夺，所以192.168.209.132上的keepalived不会切换vip过来
此时，把192.168.209.131上的mysql停掉它
查看131上的mysql和keepalived是否已经都停止了
查看192.168.209.132上是否有VIP了
最近在网上看了不少mysql锁的文章，不少文章都提到InnoDB的RR隔离级别（Repeatable Read）无法解决幻读的问题。对此问题作者亲自做了一些实验，将实验结论记录在此。
本次实验的mysql版本为5.7.22 。
此篇文章的重点在于通过实验的形式解释清楚InnoDB的RR隔离级别是否解决了幻读问题。所以文中将不会对一些相关的概念进行解释，默认读者已经具备相关知识。如果读者对于以下的知识点不甚清楚，最好自行查阅相关资料，理解清楚之后再阅读接下来的实验内容，以免造成困惑。
进行此次实验需要具备的知识点（包括但不限于）：
创建表结构：
创建两条数据：
最终的表数据如下：
打开两个终端，连上mysql，分别启动事务a和事务b。
在事务a和事务b上面分别执行如下命令：
查询出来的结果如下：
事务a：
事务b:
很明显事务b没有查询到事务a未提交的新插入数据。原因也很简单，因为 普通的select语句是快照读，而事务b启动时，它的快照数据就已经被版本锁定了 。
那么我们在事务b里面执行如下命令来看看执行结果：
执行完成之后我们发现事务b此时会block住，原因是 事务a的insert语句排它锁住了id为3的新插入数据，而事务b想请求所有行的共享锁，肯定是需要等待的。
那么此时事务b当前读id为1或2的数据（非事务a新插入数据）是否可行呢？
结论是可行的，因为 tmp_table 存在唯一键，且事务a的insert语句只是锁住了id为3的行。所以其他事务获取其他行的共享锁是可行的 。读者可以自行测试，这里就不做演示了。
事务a和事务b执行如下命令：
事务b打印的结果：
还是一样， 因为普通select是快照读，事务b还是读取到的是快照数据，所以不包含事务a提交之后的新数据 。
让我们在事务b下面使用共享锁查看当前版本数据：
结果如下：
可以查询到事务a已提交的新数据，所以此时使用当前读就产生了幻读 。
还有另一种情况也会产生幻读，并且只需要执行普通的select语句。下面请看演示。
在事务b下面执行如下两条语句：
第一条命令使用update更新了事务a已提交的新数据，第二条命令通过普通的select语句查看快照数据。
打印结果如下：
可以看到事务a已提交的新数据被事务b使用update语句更新了，并且通过普通的select语句给查询出来了，很显然，出现了幻读 。
所以说InnoDB的RR隔离级别没有或者解决了幻读问题都不太准确。应该说它并没有完全解决幻读的问题。
如果在同一个事务里面，只是总是执行普通的select快照读，是不会产生幻读的。
但是如果在这个事务里面通过当前读或者先更新然后快照读的形式来读取数据，就会产生幻读。
Phantom Rows
Innodb 中 RR 隔离级别能否防止幻读？
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）