1.MySQL数据库备份的重要性
1.1.数据丢失的原因
在生产环境中造成数据丢失的原因可能有很多种:
人为操作:在输入数据时命令错误导致数据丢失。
磁盘故障:比如由于物理磨损,导致磁盘出现坏道,造成数据丢失
服务BUG:由于数据量过大,导致MySQL服务出现逻辑错误,造成数据丢失
物理损坏:硬盘被盗、服务器物理损毁等
1.2.数据丢失的后果
数据是企业的核心资产,一次意外的数据丢失可能导致业务停滞、客户信任度下降甚至法律纠纷。MySQL数据库备份就像是给企业数据买了一份保险,能够在危机时刻快速恢复业务运行。
1.3.MySQL备份类型
数据备份的类型可根据不同的标准进行分类
1.3.1.根据数据库状态
根据备份时数据库的状态分为:
热备份:在数据库仍在运行的情况下进行备份,不影响正常的业务操作,适用于支持在线备份的数据库系统。
冷备份:在数据库完全关闭状态下进行的备份,这时的数据是静态的,不会发生变化,但会导致业务中断。
温备份:介于热备份与冷备份之间,数据库可能只允许读操作而不允许写操作,或者部分数据库实例处于待机模式。
1.3.2.根据数据的完整性
根据备份数据时,数据的完整性,即备份策略可分为:
完整备份:顾名思义,就是备份数据库的全部数据。这是最直观也最全面的备份方式,适合数据量不大或者初期备份时使用。
增量备份:只备份自上次备份以来发生改变的数据。这种方式节省空间,但恢复时需要依次恢复所有增量备份。
差异备份:备份自上次完整备份以来所有变化的数据。相比增量备份,恢复时只需要最后一次完整备份和最后一次差异备份即可。
1.3.3.根据存储介质
磁盘备份:传统的备份方式,用于大规模数据备份,现在依然在大型企业中有应用。
可移动存储备份:如U盘、光盘等。
本机多硬盘备份:利用计算机内部的多个硬盘进行备份
网络备份:通过网络将数据备份至远程服务器或其他网络存储设备。
2.生产环境迁移备份方案
根据公司实际出发,利用已有的服务器进行安全性考量,暂定的备份方案如下:
暂时无法在飞书文档外展示此内容
生产环境数据库迁移:计划将生产环境中使用的MySQL数据库迁移到一个单独的服务器上部署。
使用mysqldump脚本:通过使用mysqldump这个命令行工具来创建数据库的备份。
在数据存储服务器上创建从数据库:在数据存储服务器上创建一个从数据库,设置一个复制的数据库实例,用于数据备份或负载均衡。
增量备份:实施增量备份策略,只备份自上一次备份以来发生变化的数据,以节省存储空间和减少备份时间。
将备份文件发送至数据存储服务器:将增量备份的文件发送到数据存储服务器,将备份数据存储在远程服务器上,实现数据的冗余和安全。
主从同步:将云上新部署的数据库设置为主从同步,新数据库将作为主数据库的副本,用于读取操作或在主数据库不可用时接管服务。
3.生产环境迁移备份方案部署流程
3.1.环境准备
用测试环境数据库模拟原来的生产环境数据库
用本地虚拟机-1模拟单机部署服务器
用本地虚拟机-2的模拟数据存储服务器
主机名 |
IP地址 |
作用 |
开发环境环境 |
192.168.5.180 |
模拟老版生产环境数据库 |
本地虚拟机-1 |
192.168.88.222 |
模拟迁移后的新版生产环境数据库 |
本地虚拟机-2 |
192.168.88.223 |
模拟数据存储数据库 |
首先在本地虚拟机-1,本地虚拟机-2安装与测试环境相同版本的数据库,版本不统一会造成同步失败,主从不一致问题
由于是docker-compose部署方式 所以我们直接把开发环境的mysql-docker-compose内容直接复制下来就行,不用刻意的去挑版本了
version: '3' services: mysql: image: mysql:latest environment: MYSQL_DATABASE: 'testdb' MYSQL_USER: 'licloud' MYSQL_PASSWORD: 'licloud123' MYSQL_ROOT_PASSWORD: 'licloud123' TZ: 'Asia/Shanghai' ports: - "3306:3306" volumes: - ./mysql-data:/var/lib/mysql
本地虚拟机-1 操作 ,本地虚拟机-2 操作
mkdir /root/mysql-backup vim docker-compose.yml 将上面的内容复制到docker-compose文件中 如下所示 docker-compose up -d 启动docker-compose文件
检查一下容器是否正常,到这里环境已经配置完成
docker ps -a
3.2.老版数据库迁移
开发环境操作
docker exec -it e8321c8d440f /bin/bash # 进入mysql容器 mysqldump -uroot -p --all-databases >pro.db.sql # 全量备份所有的数据库
备份完成之后可以看见一个sql文件
docker cp all_databases.sql /root
将这个文件发送到本地虚拟机-1
docker cp all_databases.sql 0cd7a0719cc1:/ # 将这个文件拷贝到本地虚拟机-1mysql容器内 进入容器 docker exec -it 0cd7a0719cc1 /bin/bash
可以看见sql语句文件已经在容器内了
两种方式 (1)mysql -uroot -p < 文件名.sql 建议使用此方法 (2)先进入数据库 (这个方法数据文件过大容易失败) mysql -uroot -p Enter password source /指定地址/文件名.sql
到这里就已经备份完成了 我们进入数据库中检查一下库,表是否一样
show databases; 查看库 use 库名; 进入库 show tables; 查看表
开发环境
查看库
查看testdb表
本地虚拟机-1
查看库
查看testdb表
3.3.增量备份
本地虚拟机-1操作
这里在刚才迁移后的新数据库下执行脚本文件
因为我们已经将文件以数据卷的形式映射到宿主机上了 ,所以我们只需要定时增量备份宿主机上的容器卷目录
备份这个文件 然后发送到本地虚拟机-2上
增量备份脚本
mkdir mysql-backup vim mysql-backup.sh #!/bin/bash # 定义源和目标目录 source_dir="/root/mysql-new/mysql-data" backup_dir="/root/mysql-new/mysql-backup" # 创建以当前日期和时间命名的备份目录 current_datetime=$(date "+%Y%m%d_%H%M%S") backup_path="$backup_dir/mysql-pro_$current_datetime" # 创建目标备份目录 mkdir -p "$backup_path" # 使用rsync进行备份 rsync -a --delete "$source_dir/" "$backup_path/" # 完成备份 echo "备份已完成,文件备份到: $backup_path"
chmod +x mysql-backup.sh 给脚本增加权限 bash mysql-backup.sh
执行完成之后我们就能看见文件夹下面有一个以时间命名的文件夹
对比一下可以看见文件夹的内容是一样的 第一次是全量备份
然后我们设置一个定时任务
3.4.主从同步
将本地虚拟机-1做为主数据库,将本地虚拟机-2做为从数据库
主库本地虚拟机-1操作
docker ps -a 先查看一下数据库容器的ID
docker exec -it 0cd7a0719cc1 /bin/bash 进入到数据库容器内
进入到数据库容器内
打开配置文件
cd /etc/mysql/conf.d vim mysql.cnf
# [mysqld] # 若是配置文件中有就不带 server-id = 1 # 节点ID,确保唯一,用来区分服务器的编号 # log config log-bin = master-bin #开启mysql的binlog日志功能(就会创建二进制文件
在配置文件中添加下面两行,我们采取binlog的方式同步数据
保存退出
exit # 退出容器 systemctl restart mysql-docker # 重启容器
重启完成之后再进入容器,进入mysql数据库
mysql -p 回车 输入密码
查看master配置信息(需进入mysql命令行):show master status
,获取到binlog文件名称以及偏移量,之后从服务器配置应当按照主服务器来,这样才能找到binlog位置
保存下来 待会儿要用到
从库本地虚拟机-2操作
进入从库数据库容器
依旧是在/etc/mysql/conf.d/mysql.cnf中添加即可 只需要添加 [mysqld] server-id = 2 #注意 id号和主库不能相同
后面的操作依旧相同 保存退出 重启容器, 进入数据库
\e 将下面这段直接粘贴进去 然后修改对应的信息 CHANGE MASTER TO MASTER_HOST = '192.168.88.222', # 目标服务器(即主服务器)的主机地址 MASTER_USER = 'root', # 登陆主服务器的用户名 MASTER_PASSWORD = 'licloud123', # 登陆主服务器的密码 MASTER_PORT = 3306, # 主服务器开放mysql的端口 # 下面两个是在主服务器中查询到的,使用show master status查询 MASTER_LOG_FILE='master-bin.000001', #这里和下面一行填写我们上面保存的主库信息 MASTER_LOG_POS=156; # MASTER_LOG_FILE='mysql-bin.000005',#与主库File 保持一致 # MASTER_LOG_POS=120 , #与主库Position 保持一致
保存退出
start slave; # 开启从服务器(服从) # 关闭从服务器 stop slave
show slave status\G; 查看一下IO和SQL状态 必须是双yes才成功 有一个不是 都不行
到这里我们主从备份就已经做完了 我们验证一下
主库本地虚拟机-1操作
主库本地虚拟机-2操作
主库本地虚拟机-1操作
在主库中创建一个新的库和表 表里插入内容
CREATE DATABASE xcl_db; 创建数据库 use xcl_db 使用数据库 create table user (id int,username varchar(10),age int); INSERT INTO users (id, username,age) VALUES ('1','xcl','18');
创建完成之后我们查看一下从库
刚才创建的库和表都已经同步了
4.使用docker容器和直接安装的优劣对比
4.1.传统方式部署MySQL
优势:
性能: 直接在宿主机上部署MySQL通常可以获得最佳的性能,因为没有额外的虚拟化层。
资源控制: 可以更精细地控制资源分配,如CPU、内存和磁盘I/O。
兼容性: 直接在操作系统上安装MySQL通常更容易与系统服务和其他软件集成。
调试和优化: 直接访问系统文件和配置,便于进行调试和性能优化。
劣势:
环境一致性: 在不同的服务器上部署时,可能会遇到环境不一致的问题,导致配置和依赖项不匹配。
隔离性: 应用程序和MySQL服务共享同一操作系统,可能会相互影响。
部署和扩展: 部署新的MySQL实例或扩展集群可能需要更多的时间和手动配置。
依赖管理: 需要手动管理MySQL及其依赖项的安装和更新。
4.2.Docker部署MySQL
优势:
环境一致性: Docker容器提供了一致的环境,无论在开发、测试还是生产环境中,都可以确保MySQL运行在相同的环境下。
隔离性: 容器提供了良好的进程隔离,MySQL容器不会影响宿主机或其他容器。
快速部署: 使用Docker可以快速部署和启动MySQL实例,便于扩展和复制。
易于管理: Docker镜像和容器管理工具使得MySQL的安装、更新和回滚变得更加简单。
资源效率: Docker容器通常比虚拟机更轻量,可以更有效地利用系统资源。
劣势:
性能: 虽然Docker的性能损失通常很小,但在某些情况下,容器化可能会引入轻微的性能开销。
复杂性: 对于不熟悉Docker的用户来说,可能需要学习新的工具和概念。
资源限制: Docker容器可能需要额外的配置来限制资源使用,以防止某个容器占用过多资源。
存储管理: Docker容器的存储管理可能比直接在宿主机上安装MySQL更复杂。
4.3.总结
选择传统方式还是Docker部署MySQL取决于具体的需求和环境。如果需要最佳性能和精细的资源控制,传统方式可能更合适。如果追求环境一致性、快速部署和易于管理,Docker则是一个很好的选择。在实际应用中,许多组织会根据具体情况结合使用这两种方法。