mysql5.7 迁移以及从库提升为主库

CHANGE MASTER TO
MASTER_HOST='10.10.30.34', 
MASTER_PORT=3306,
MASTER_USER='slave',
MASTER_PASSWORD='slave',
MASTER_LOG_FILE='mysql-bin.000148',
MASTER_LOG_POS=154;
从数据库变为主库
stop slave;
reset slave;
reset master;
从库变为刚才的主库(由从库变为主库的数据库)
vim /etc/my.cnf
log-bin=mysql-bin  #并重启数据库,主库开启binlog日志
主库操作:show  master status
主库操作:scp -r /var/lib/mysql/*   10.10.50.34:/var/lib/mysql/
从库:chown  -R mysql.mysql   /var/lib/mysql/
从库:systemctl restart  mysqld 
CHANGE MASTER TO
MASTER_HOST='172.16.1.51', 
MASTER_PORT=3306,
MASTER_USER='rep',
MASTER_PASSWORD='123456',
MASTER_LOG_FILE='mysql-bin.000001',
MASTER_LOG_POS=335;
进入数据:start slave;
中间报错:
1.IO进程一直处于connnecting中
  slave 用户的密码写错
2.show slave  status;报错
Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'Could not find first log file name in binary log index file'
解决办法:
主库:flush logs;
从库:
stop slave;
CHANGE MASTER TO MASTER_LOG_FILE='mysqld-bin.000011',MASTER_LOG_POS=106;
start slave;

时间: 2024-10-11 23:41:29

mysql5.7 迁移以及从库提升为主库的相关文章

postgresql从库提升为主库

一.停主库 1.查看当前连接 select pid,datname,usename,client_addr,client_port, application_name from pg_stat_activity; 2.杀死当前账户连接 select pg_terminate_backend(pid) from pg_stat_activity where usename='postgres' ; 3.停止主库服务 pg_ctl stop -m fast -D /usr/local/postgre

mysql主从复制、半同步复制、主主复制、及从库升级为主库讲解

一.主从复制结构 binlog dump --- io thread  ---  relay log ---- sql thread 1.总体讲解 主从复制时是异步的 半同步是在主从架构下安装插件来达到半同步的 半同步的优点:保证至少一个节点的数据和主节点的数据一致,缺点影响性能 导致主从不同步的原因是 现在的服务器都是单核多线程或者多核多线程,导致主节点可以同时执行多条读写操作,而记录二进制日志则必须按顺序有先后的记录,从节点在一条一条复制过去,生成中继日志,再执行语句. 多个库复制的话,可以

主库down机,从库切换为主库的步骤

以1主2从架构为例,介绍主库down机后,将某一从库提升为库的步骤: 主库/从库 IP地址 端口 同步帐号 主 172.18.130.231 3306 从1 172.18.130.236 3306 rep/123456 从2 172.18.130.237 3306 rep/123456 一般主库突然down机,以主从库binlog的同步情况分为2种 两从与主库完全同步 两从与主库不同步,数据不一致. a.      主库down机(主库连不上,系统无法启动)后,直接选一台从库切换为主库: b. 

当主库发生宕机,从库如何接管主库

当主库发生宕机,从库如何接管主库 1.主库崩溃,日志不在情况(会丢数据) 查看从库已经同步到哪了,①确定数据丢失的时间范围,②确定从库的中继日志是否被SQL_thread进程解析完(即传输过来的中断日志是否在从库上重放完). 1.1.如何确定数据丢失的时间范围 登录从库服务器,进入mysql数据库,执行以下命令,查看相关的参数: mysql> show slave status\G Master_Log_File            表示IO thread读取到的binlog日志文件名 Rea

oracle dg 备库不同步主库数据

今天遇到一个数据库同步问题,主库被关闭,重启主库后,备库不能正常同步主库数据.只有当手动切换归档日志的时候,备库才能和主库一致. 这个问题的解决方法: 重启备库,重新应用归档日志. 操作步骤如下: //关闭备库监听器 lsnrctl stop //关闭备库 sqlplus / as sysdba alter database recover managed standby database cancel; shutdown immediate; //启动备库 startup nomount; a

MySQL5.7迁移表空间——普通表

Mysql 传输表空间--将InnoDB表复制到另一个实例(一) ---在工作中经常遇到将一个InnoDB表从一个实例,移动或者复制到另一个实例,其实有很多的方法,在5.6之前常用的是通过物理或者逻辑备份来实现.在5.6.6+的版本中,用到了一种基于表空间迁移的快速方法,即类似Oracle TTS.下面本次测试在MySQL5.7环境中迁移普通表. 实验环境:(都是mysql5.7) 源库:192.168.2.200      mysql5.7.16  zhangdb下的emp表 目标库:192.

oracle11g文件系统库迁移到ASM库上面

最近把oracle11g的文件系统库迁移到了asm库上面. 迁移过程大致如下: 最少停机方案: 实例joinpay02 | |数据库joinpay02 需要改动的文件: 数据文件 控制文件 redo文件 过程总结: 拷贝数据文件到asm中(备份)(此步骤时间长) 用joinpay02 生成参数文件pfile 伪实例j01用pfile和joinpay02拷贝过来的的控制文件启动实例到mount状态 伪实例j01:使用rman修改控制文件(指向asm存储内的数据文件和控制文件),并recover数据

mysql5.1迁移到mysql5.7

1.增加utf8mb4的支持 SHOW VARIABLES WHERE Variable_name LIKE 'character%' OR Variable_name LIKE 'collation%'; 2.xtrabackup 因为测试环境都是5.7,所以需要升级. 具体步骤 mysql5.7 shell自动安装脚本 2.xtarbackup备份测试库,还原到现在的新安装的库 如果直接导入5.1的mysql库,重新启动会报错 3.清空新安装的库所有表 4.备份原来5.1的库,过滤一些表 F

基于mysql5.6版本的主从库同步

系统:centos6.4 mysql版本:5.6.17 主库:192.168.31.111 从库:192.168.31.235 主库操作: 1.配置my.cnf文件开启二进制日志 log_bin = on server_id = 1 2.建立用于同步数据库的账号rep grant replication slave on *.* to 'rep'@'192.168.31.%' identified by 'redhat'; select user,host,password from mysql