mysql主库清理数据,从库保留

因为业务需要,想在mysql主库清理一些数据,但从库想要保留,根据网友介绍,可以根据binlog跳过清理的命令 

1.确保主从同步的情况下,主库开始操作 
mysql> flush logs;                    --刷新日志,切换一个新的binlog日志,比较小,后面修改就会方便些 
Query OK, 0 rows affected (0.21 sec) 

mysql> show master status \G 
*************************** 1. row *************************** 
             File: mysql-bin.000039    --这里的binlog位置后面不会用到 
         Position: 33958 
     Binlog_Do_DB: 
Binlog_Ignore_DB: 
Executed_Gtid_Set: 
1 row in set (0.03 sec) 

2.从库停止同步    ---第1.2步尽量要快速操作 
mysql> stop slave; 
Query OK, 0 rows affected (0.05 sec) 

mysql> show slave status \G 
*************************** 1. row *************************** 
               Slave_IO_State: 
                  Master_Host: 192.168.1.196 
                  Master_User: repli 
                  Master_Port: 3306 
                Connect_Retry: 60 
              Master_Log_File: mysql-bin.000039 
          Read_Master_Log_Pos: 488906 
               Relay_Log_File: mysql-relay-bin.000016 
                Relay_Log_Pos: 489119 
        Relay_Master_Log_File: mysql-bin.000039 
             Slave_IO_Running: No 
            Slave_SQL_Running: No 

3.主库清空数据 

mysql> truncate table t2;   步骤a 
Query OK, 0 rows affected (0.46 sec) 

mysql> show master status \g  步骤b 
+------------------+----------+--------------+------------------+-------------------+ 
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set | 
+------------------+----------+--------------+------------------+-------------------+ 
| mysql-bin.000039 |  1942762 |              |                  |                   | 
+------------------+----------+--------------+------------------+-------------------+ 
1 row in set (0.06 sec) 

/usr/local/mysql/bin/mysqlbinlog mysql-bin.000039 >000039.sql   步骤c 

4.编辑000039.sql,删掉truncate语句    
truncate table t2 /*!*/;   ---删掉的内容 

查找1942762  找不到该位置的话,可能会丢失数据,因此前面的三步abc一定要注意顺序!最好sql里面是包含这个位置信息的,然后删掉后面的内容,避免后面日志应用的时候,重复操作。 

end_log_pos 1942762   将这个位置后面的内容全部干掉! 

5.从库恢复 
/usr/local/mysql/bin/mysql -umydba -p 
source /root/000039.sql 
mysql> change master to master_log_file='mysql-bin.000039',master_log_pos=1942762; 
Query OK, 0 rows affected (0.19 sec) 

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

mysql> show slave status \G 
*************************** 1. row *************************** 
               Slave_IO_State: Waiting for master to send event 
                  Master_Host: 192.168.1.196 
                  Master_User: repli 
                  Master_Port: 3306 
                Connect_Retry: 60 
              Master_Log_File: mysql-bin.000039 
          Read_Master_Log_Pos: 10009221 
               Relay_Log_File: mysql-relay-bin.000002 
                Relay_Log_Pos: 8066779 
        Relay_Master_Log_File: mysql-bin.000039 
             Slave_IO_Running: Yes 
            Slave_SQL_Running: Yes 
              Replicate_Do_DB: 
          Replicate_Ignore_DB: 
           Replicate_Do_Table: 
       Replicate_Ignore_Table: 
      Replicate_Wild_Do_Table: 
  Replicate_Wild_Ignore_Table: 
                   Last_Errno: 0 
                   Last_Error: 
                 Skip_Counter: 0 
          Exec_Master_Log_Pos: 10009221 
              Relay_Log_Space: 8066986 
              Until_Condition: None 
               Until_Log_File: 
                Until_Log_Pos: 0 
           Master_SSL_Allowed: No 
           Master_SSL_CA_File: 
           Master_SSL_CA_Path: 
              Master_SSL_Cert: 
            Master_SSL_Cipher: 
               Master_SSL_Key: 
        Seconds_Behind_Master: 0 
Master_SSL_Verify_Server_Cert: No 
                Last_IO_Errno: 0 
                Last_IO_Error: 
               Last_SQL_Errno: 0 
               Last_SQL_Error: 
  Replicate_Ignore_Server_Ids: 
             Master_Server_Id: 1 
                  Master_UUID: 701cbadc-ba33-11e5-9091-305a3a78baf2 
             Master_Info_File: /usr/local/mysql/data/master.info 
                    SQL_Delay: 0 
          SQL_Remaining_Delay: NULL 
      Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates 
           Master_Retry_Count: 86400 
                  Master_Bind: 
      Last_IO_Error_Timestamp: 
     Last_SQL_Error_Timestamp: 
               Master_SSL_Crl: 
           Master_SSL_Crlpath: 
           Retrieved_Gtid_Set: 
            Executed_Gtid_Set: 
                Auto_Position: 0 
         Replicate_Rewrite_DB: 
                 Channel_Name: 
           Master_TLS_Version: 
1 row in set (0.00 sec) 

---主从同步,跳过了truncate这个命令 

6.验证 
主库: 
mysql> select * from t2; 
Empty set (0.00 sec) 

从库: 
mysql> select * from t2; 
+----+ 
| id | 
+----+ 
|  1 | 
|  2 | 
|  3 | 
|  4 | 
|  5 | 
+----+ 
5 rows in set (0.00 sec)

时间: 2024-10-23 03:14:31

mysql主库清理数据,从库保留的相关文章

【大数据新手上路】“零基础”系列课程--MySQL 数据整库迁移到 MaxCompute

随着公司业务的增多,云数据库 RDS 下的 MySQL 数据库的表越来越多,想要把它全部迁移到 MaxCompute 中进行计算分析,但又愁要配置太多次同步任务.如何能将大量的数据表一次性上传到 MaxCompute 中呢?通过大数据开发套件的整库迁移功能,便可快速完成 MySQL 数据整库迁移到 MaxCompute,从而节省同步时间,提高工作效率. 下面介绍一个适用于中小企业用户,高效率低成本的数据同步方案: 对于自建或云数据库 RDS 的 MySQL 数据库中的数据,都可以通过整库迁移功能

mysql查找删除重复数据并只保留一条实例详解

有这样一张表,表数据及结果如下: school_id school_name total_student test_takers 1239 Abraham Lincoln High School 55 50 1240 Abraham Lincoln High School 70 35 1241 Acalanes High School 120 89 1242 Academy Of The Canyons 30 30 1243 Agoura High School 89 40 1244 Agour

Uber是如何使用MySQL设计可扩展性数据存储的?

在Mezzanine项目中我们描述了我们是如何将Uber的核心行程数据从单个的Postgres节点迁移到Schemaless,这是我们开发的一个容错性很高.可用的数据存储. 根据Uber工程师的习惯使用MySQL设计的数据存储,使我们可以从2014 扩容到更高.本文分成三部分对Schemaless进行阐述. 一.Schemaless的总体设计   这一部分我们将讲述Schemaless的架构它在Uber基础结构中的角色以及他是如何成为该角色的. 1.我们对新数据库的迫切需求 2014年初,由于出

应对亿级访问,另辟蹊径实现MySQL主库高可用

   关于如何实现MySQL主库高可用,是一个老生常谈的问题了,目前开源方案主要有MHA和MMM,各有优缺吧.笔者比较推崇的一个原则是"引入尽可能少的东西来满足需求",所以先想到了"经典"的双主+keepalived架构.关于这个架构,网络上的资料基本都仅停留在对server和MySQL进程层面的监控来决定keepalived是否切换vip,其实这样做是远远不足以保证主库可用性及双主数据一致性的. 举例来说:很多时候主库不可用是由于负载过高或者是达到最大连接数等因素

MySQL 自动清理binlog日志的方法_Mysql

说明: 开启MySQL binlog日志的服务器,如果不设置自动清理日志,默认binlog日志一直保留着,时间一长,服务器磁盘空间被binlog日志占满,导致MySQL数据库出错. 使用下面方法可以安全清理binlog日志 一.没有主从同步的情况下清理日志 mysql -uroot -p123456 -e 'PURGE MASTER LOGS BEFORE DATE_SUB( NOW( ),INTERVAL 5 DAY)'; #mysql 定时清理5天前的binlog mysql -u root

MySQL · 捉虫动态 · 备库1206错误问题说明

问题背景 一个用户自建MySQL,出现备库复制中断的问题,报错为slave sql thread 错误,The total number of locks exceeds the lock table size. 报错代码 这个报错在代码中的抛错逻辑为: if UT_LIST_GET_LEN(buf_pool->free) + UT_LIST_GET_LEN(buf_pool->LRU) < buf_pool->curr_size / 4 文字解释是:如果buffer pool中的

建立STANDBY数据库时在ASM上恢复主库的数据文件出现ORA-15173错误

建立STANDBY数据库时,在ASM上恢复主库的数据文件出现了ORA-15173错误. 主库和备库都是单实例数据库,不过都使用ASM作为存储方式. 在备库上利用主库的备份进行restore database操作,碰到了这个错误: [oracle@localhost data]$ rman target / Recovery Manager: Release 10.2.0.3.0 - Production on Sat Feb 12 14:43:29 2011 Copyright (c) 1982

MySQL导入导出数据出现乱码的解决办法

  在mysql导入导出数据时经常出现中文乱码的问题,大多是因类导入导出时编码设置不一致所引起的.本文介绍了不同平台下的编码转换方法,供大家参考. 在linux系统中默认的是utf8编码,而windows是gbk编码,如果在这二个系统间导入未经指定编码的数据,就会出现乱码. 首先,确定导出数据的编码格式,使用mysqldump的时候需要加上--default-character-set=utf8, 例如: mysqldump -uroot -p --default-character-set=u

oracle清理数据的方法

oracle清理数据的方法 一.删除一个用户下所有数据库对象 一种方法是删除这个用户然后重建,需要管理员操作: drop user wangyi cascade; --删除用户select * from dba_users where username = 'wangyi' --查询默认表空间drop tablespace WANGYI_DTBS including contents and datafiles; --删除表空间 重建用户: create user wangyi identifi