使用Innobackupex快速搭建(修复)MySQL主从架构

爱被打了一巴掌 2022-08-07 01:44 206阅读 0赞
  1. MySQL的主从搭建大家有很多种方式,传统的mysqldump方式是很多人的选择之一。但对于较大的数据库则该方式并非理想的选择。使用Xtrabackup可以快速轻松的构建或修复mysql主从架构。本文描述了使用innobackupex快速来搭建或修复主从架构。供大家参考。
  2. 1、基于主库做一个完整备份
  3. # mkdir -p /log/bakforslave
  4. # innobackupex --user=root -password=*** --socket=/tmp/mysql.sock \
  5. --defaults-file=/etc/my.cnf /log/bakforslave --parallel=3 --safe-slave-backup --no-timestamp
  6. 2、复制数据库到备机
  7. # tar -czvf bakforslave.tar.gz ./bakforslave/
  8. # scp bakforslave.tar.gz robin@172.16.10.51:~
  9. # scp /etc/my.cnf robin@172.16.10.51:~/mymaster.cnf
  10. 3、在备机上恢复
  11. ###备机解压打包的备份文件
  12. # mv /home/robin/bakforslave.tar.gz /data
  13. # cd /data
  14. # tar -xvf bakforslave.tar.gz
  15. ### prepare 备份
  16. # innobackupex --user=root -password=*** --socket=/tmp/mysql.sock --defaults-file=/home/robin/mymaster.cnf \
  17. --apply-log --use-memory=4GB /data/bakforslave
  18. ###如果是修复从库,从库为启动状态应先停止从库,再做如下操作,否则可以跳过
  19. # service mysqld stop
  20. ###还原备份的数据文件
  21. # mv mysqldata mysqldatabk
  22. # mv bakforslave mysqldata
  23. # chown -R mysql:mysql mysqldata
  24. ###如果是新搭建的从库,此时可以修改主库的my.cnf为本机的my.cnf,
  25. ###如果为修复,则可以直接使用原有的配置文件或根据需要修改。
  26. # cp /home/robin/mymaster.cnf /etc/my.cnf
  27. # vi /etc/my.cnf ###此处应修改使用一个不同的server_id,同时可以根据需要修改相关路径及端口配置等。
  28. # service mysqld start ###修改完毕后可以启动mysqld
  29. 4、主库授权用于复制的用户
  30. mysql> grant replication slave,replication client on *.* to repl2@'172.16.10.%' identified by '***';
  31. ### 验证shell 提示符下登陆到主库
  32. # mysql -urepl2 -p -h172.16.10.88
  33. 5、启动slave
  34. # more /data/mysqldata/xtrabackup_binlog_info
  35. mysql-bin.000136 73752825
  36. mysql> CHANGE MASTER TO
  37. MASTER_HOST='172.16.10.88', --Author: Leshami
  38. MASTER_USER='repl2', --Blog : http://blog.csdn.net/leshami
  39. MASTER_PASSWORD='***',
  40. MASTER_LOG_FILE='mysql-bin.000136',
  41. MASTER_LOG_POS=73752825;
  42. mysql> start slave;
  43. 6、验证结果
  44. mysql> show slave status \G
  45. *************************** 1. row ***************************
  46. Slave_IO_State: Waiting for master to send event
  47. Master_Host: 172.16.10.88
  48. Master_User: repl2
  49. Master_Port: 3306
  50. Connect_Retry: 60
  51. Master_Log_File: mysql-bin.000136
  52. Read_Master_Log_Pos: 96592981
  53. Relay_Log_File: mysqld-relay-bin.000002
  54. Relay_Log_Pos: 72113
  55. Relay_Master_Log_File: mysql-bin.000136
  56. Slave_IO_Running: Yes
  57. Slave_SQL_Running: Yes
  58. Replicate_Do_DB: test,bs_com,bs_sysmsg,bs_bak
  59. Replicate_Ignore_DB: mysql
  60. Replicate_Do_Table:
  61. Replicate_Ignore_Table:
  62. Replicate_Wild_Do_Table:
  63. Replicate_Wild_Ignore_Table:
  64. Last_Errno: 0
  65. Last_Error:
  66. Skip_Counter: 0
  67. Exec_Master_Log_Pos: 73824655
  68. Relay_Log_Space: 22840613
  69. Until_Condition: None
  70. Until_Log_File:
  71. Until_Log_Pos: 0
  72. Master_SSL_Allowed: No
  73. Master_SSL_CA_File:
  74. Master_SSL_CA_Path:
  75. Master_SSL_Cert:
  76. Master_SSL_Cipher:
  77. Master_SSL_Key:
  78. Seconds_Behind_Master: 3815
  79. Master_SSL_Verify_Server_Cert: No
  80. Last_IO_Errno: 0
  81. Last_IO_Error:
  82. Last_SQL_Errno: 0
  83. Last_SQL_Error:
  84. Replicate_Ignore_Server_Ids:
  85. Master_Server_Id: 2
  86. Master_UUID: afd6bca4-6636-11e3-9d60-74867ae1c47c
  87. Master_Info_File: /data/mysqldata/master.info
  88. SQL_Delay: 0
  89. SQL_Remaining_Delay: NULL
  90. Slave_SQL_Running_State: updating
  91. Master_Retry_Count: 86400
  92. Master_Bind:
  93. Last_IO_Error_Timestamp:
  94. Last_SQL_Error_Timestamp:
  95. Master_SSL_Crl:
  96. Master_SSL_Crlpath:
  97. Retrieved_Gtid_Set:
  98. Executed_Gtid_Set:
  99. Auto_Position: 0
  100. 1 row in set (0.00 sec)

发表评论

表情:
评论列表 (有 0 条评论,206人围观)

还没有评论,来说两句吧...

相关阅读

    相关 MySQL主从架构

    一、MySQL高可用集群介绍 1-1、数据库主从架构与分库分表   随着现在互联网的应用越来越大,数据库会频繁的成为整个应用的性能瓶颈。而我们经常使用的MySQL数

    相关 redis主从架构

    一.绪论    Redis的复制功能是基于内存快照的持久化策略基础上的,也就是说无论你的持久化策略选择的是什么,只要用到了Redis的复制功能,就一定会有内存快照发生。