• linkedu视频
  • 平面设计
  • 电脑入门
  • 操作系统
  • 办公应用
  • 电脑硬件
  • 动画设计
  • 3D设计
  • 网页设计
  • CAD设计
  • 影音处理
  • 数据库
  • 程序设计
  • 认证考试
  • 信息管理
  • 信息安全
菜单
linkedu.com
  • 网页制作
  • 数据库
  • 程序设计
  • 操作系统
  • CMS教程
  • 游戏攻略
  • 脚本语言
  • 平面设计
  • 软件教程
  • 网络安全
  • 电脑知识
  • 服务器
  • 视频教程
  • MsSql
  • Mysql
  • oracle
  • MariaDB
  • DB2
  • SQLite
  • PostgreSQL
  • MongoDB
  • Redis
  • Access
  • 数据库其它
  • sybase
  • HBase
您的位置:首页 > 数据库 >Mysql > 使用innobackupex基于从库搭建mysql主从架构

使用innobackupex基于从库搭建mysql主从架构

作者:匿名 字体:[增加 减小] 来源:互联网 时间:2018-12-05

匿名通过本文主要向大家介绍了innobackupex,mysql,主从架构等相关知识,希望本文的分享对您有所帮助
??

MySQL的主从搭建大家有很多种方式,传统的mysqldump方式是很多人的选择之一。但对于较大的数据库则该方式并非理想的选择。使用Xtrabackup可以快速轻松的构建或修复mysql主从架构。本文描述了基于现有的从库来快速搭建主从,即作为原主库的一个新从库。该方式的好处是对主库无需备份期间导致的相关性能压力。搭建过程中使用了快速流备份方式来加速主从构建以及描述了加速流式备份的几个参数,供大家参考。


有关流式备份可以参考:Xtrabackup 流备份与恢复


1、备份从库
###远程备份期间使用了等效性验证,因此应先作相应配置,这里我们使用的是mysql用户

$ innobackupex --user=root --password=xxx --slave-info --safe-slave-backup 
\--compress-threads=3 --parallel=3 --stream=xbstream \--compress /log | ssh -p50021 mysql@172.16.16.10 "xbstream -x -C /log/recover"



###备份期间使用了safe-slave-backup参数,可以看到SQL thread被停止,完成后被启动

$ mysql -uroot -p -e "show slave status \G"|egrep 'Slave_IO_Running|Slave_SQL_Running'
Enter password: 
             Slave_IO_Running: Yes
            Slave_SQL_Running: No
      Slave_SQL_Running_State: Slave has read all relay log; waiting for the slave I/O thread to update it



###复制my.cnf文件到新从库

$ scp -P50021 /etc/my.cnf mysql@172.16.16.10:/log/recover



2、主库授予新从库复制账户

master@MySQL> grant replication slave,replication client on *.* to repl@'172.16.%.%' identified by 'repl';



3、新从库prepare
###由于使用了流式压缩备份,因此需要先解压
###下载地址
http:///

# tar -xvf qpress-11-linux-x64.tar qpress# cp qpress /usr/bin/
$ innobackupex --decompress /log/recover                               
###解压$ innobackupex --apply-log --use-memory=2G /log/recover    
###prepare备份



4、准备从库配置文件my.cnf
###根据需要修改相应参数,这里的修改如下,

skip-slave-start
datadir = /log/recover
port = 3307
server_id = 24                     
socket = /tmp/mysql3307.sock
pid-file=/log/recover/mysql3307.pid
log_error=/log/recover/recover.err


5、启动从库及修改change master
# chown -R mysql:mysql /log/recover
# /app/soft/mysql/bin/mysqld_safe --defaults-file=/log/recover/my.cnf &

mysql> system more /log/recover/xtrabackup_slave_info
CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000658', MASTER_LOG_POS=925384099
mysql> CHANGE MASTER TO
    -> MASTER_HOST='172.16.16.10',       
### Author: Leshami
    -> MASTER_USER='repl',                    
 ### Blog  : 
http:///
    -> MASTER_PASSWORD='repl',
    -> MASTER_PORT=3306,
    -> MASTER_LOG_FILE='mysql-bin.000658',
    -> MASTER_LOG_POS=925384099;
Query OK, 0 rows affected, 2 warnings (0.31 sec)


mysql> start slave;
Query OK, 0 rows affected (0.02 sec)


6、基于从库备份相关参数及加速流备份参数

The --slave-info option This option is useful when backing up a replication slave server. It prints the binary
log position and name of the master server. It also writes this information to the xtrabackup_slave_info ?le
as a CHANGE MASTER statement.
This is useful for setting up a new slave for this master can be set up by starting a slave server on this backup and
issuing the statement saved in the xtrabackup_slave_info ?le.



The --safe-slave-backup option In order to assure a consistent replication state, this option stops the slave
SQL thread and wait to start backing up until Slave_open_temp_tables in SHOW STATUS is zero. If there are
no open temporary tables, the backup will take place, otherwise the SQL thread will be started and stopped until there
are no open temporary tables. The backup will fail if Slave_open_temp_tables does not become zero after
--safe-slave-backup-timeout seconds (defaults to 300 seconds). The slave SQL thread will be restarted
when the backup ?nishes.
Using this option is always recommended when taking backups from a slave server.



Warning: Make sure your slave is a true replica of the master before using it as a source for backup. A good tool
to validate a slave is pt-table-checksum.


--compress

    This option instructs xtrabackup to compress backup copies of InnoDB
        data files. It is passed directly to the xtrabackup child process.

###注compress方式是一种相对粗糙的压缩方式,压缩为.gp文件,没有gzip压缩比高


--compress-threads

   This option specifies the number of worker threads that will be used
        for parallel compression. It is passed directly to the xtrabackup
        child proc
  


 
分享到:QQ空间新浪微博腾讯微博微信百度贴吧QQ好友复制网址打印

您可能想查找下面的文章:

  • MySQL使用innobackupex备份连接服务器失败的代码案例
  • 使用Innobackupex快速搭建(修复)MySQL主从架构
  • 使用innobackupex基于从库搭建mysql主从架构
  • MySQL中使用innobackupex、xtrabackup进行大数据的备份和还原教程

相关文章

  • 2017-05-11MySQL无法启动、无法停止解决方法(安全设置后容易出现)
  • 2018-12-05手工还原SQL时提示xp_dirtree出错的处理办法
  • 2018-12-05对MySQL服务器连接过程的讲解分析
  • 2018-12-05MySQL数据库在Linux下卸载的详细介绍
  • 2018-12-05分享一个纯 Python 实现的 MySQL 客户端操作库
  • 2018-12-05mysql服务器查询慢原因分析与解决方法小结
  • 2018-12-05什么是Access数据库,第一课认识ACCESS数据库
  • 2018-12-05Oracle如何更改表空间的数据文件位置
  • 2018-12-05理解redo(11)truncate和select的redo
  • 2017-05-11mysql 导入导出数据库以及函数、存储过程的介绍

文章分类

  • MsSql
  • Mysql
  • oracle
  • MariaDB
  • DB2
  • SQLite
  • PostgreSQL
  • MongoDB
  • Redis
  • Access
  • 数据库其它
  • sybase
  • HBase

最近更新的内容

    • MYSQL随机抽取查询 MySQL Order By Rand()效率问题
    • mysql 服务意外停止1067错误解决办法小结
    • mysql导入sql文件命令和mysql远程登陆使用详解
    • MySQL实例讲解:添加账户、授予权限、删除用户
    • MySQL性能优化的一些技巧帮助你的数据库
    • mysql中mydumper 和 mysqldump对比使用详解
    • 在MySQL数据库中把int类型转化varchar类型引发的慢查询问题
    • MySQL错误“Specified key was too long; max key length is 1000 bytes”的解决办法
    • 如何快速掌握基本MySQL?
    • 当mysqldump --single-transaction遇到alter table怎么办?

关于我们 - 联系我们 - 免责声明 - 网站地图

©2020-2025 All Rights Reserved. linkedu.com 版权所有