将MySQL-mmm Master从REPLICATION_FAIL状态恢复

本文涉及的产品
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
云数据库 RDS MySQL,集群系列 2核4GB
推荐场景:
搭建个人博客
云数据库 RDS MySQL,高可用系列 2核4GB
简介:         估计是糗百看多了,总是先要交待一下背景。        几天前网站突然不能访问了,页面上除了框架没有任何内容。从系统的运行日志看到的错误信息有:Communications link failureThe last packet successfully received from the server was 7,875,055 milliseconds ago.

        估计是糗百看多了,总是先要交待一下背景。

        几天前网站突然不能访问了,页面上除了框架没有任何内容。从系统的运行日志看到的错误信息有:

Communications link failure

The last packet successfully received from the server was 7,875,055 milliseconds ago.  The last packet sent successfully to the server was 7,875,055 milliseconds ago.

 最后看到一句:

Caused by: java.sql.SQLException: The table 'message' is full

         这个太不可思议了。在还没有当前用户量的情况不能出现数据库写满的情况。于是到数据库服务器Master1上查看,通过df -h命令查看,发现/var/已经满了。这是才记起来:当时数据库创建时,所有的数据文件都放在了另外一个目录下,然后/var/lib/mysql/下面是softlink。现在这种情况,肯定当时建过表后,没有移动到那个目录下。接下来步骤就是:

1. service mysql stop停止MySQL服务

2. 将数据表文件移动到指定目录,建立softlink

3. service mysql start启动MySQL服务

4. 到MySQL-mmm上通过mmm_control set_offline db01,然后mmm_control set_online db01,将master01重新上线。

之后通过mmm_control show 查看状态,已经是ONLINE了。


        这样就结束了,NO! NO! 按照糗百(我在为糗百做广告,绝对没有)的惯例这不是GC。

        今天在听一个报告的时候,突然想上去看看MySQL-mmm的运行状态。mmm_control show,不愿意看到的一幕出现了,db01的状态是REPLICATION_FAIL,set_offline, set_online,重新启动MySQL服务统统失效。

        到db01上查看错误日志,看到了下面的信息:

111104 13:19:19 [ERROR] /usr/sbin/mysqld: Table 'table1' is marked as crashed and should be repaired
111104 13:19:19 [ERROR] Slave SQL: Error 'Table 'table1' is marked as crashed and should be repaired' on query. Default database: 'db1'. Query: '...'
111104 13:19:19 [Warning] Slave: Table './db1/table1' is marked as crashed and should be repaired Error_code: 145
111104 13:19:19 [Warning] Slave: Table 'table1' is marked as crashed and should be repaired Error_code: 1194
111104 13:19:19 [ERROR] Error running query, slave SQL thread aborted. Fix the problem, and restart the slave SQL thread with "SLAVE START". We stopped at log 'mysql-bin-master2.000022' position 110544518

       登录到数据库,执行:

mysql> repair table table1;
mysql> start slave;
   
       再查看错误日志,可以看到:

111104 13:19:19 [Note] Slave I/O thread: connected to master 'replication@db02:3306',replication started in log 'mysql-bin-master2.000022' at position 679172934
111104 13:24:18 [Note] Found 11845 of 11846 rows when repairing './db1/table1'
111104 13:27:03 [Note] Slave SQL thread initialized, starting replication in log 'mysql-bin-master2.000022' at position 110544518, relay log '/mysql/log_vol/replication/mysql-bin-master1.004525' position: 844646

     到MySQL-mmm监控服务器上查看状态,可以看到db01从REPLICATION_FAIL到REPLICATION_DELAY到ONLINE。等了一会儿,一直都是ONLINE状态,看来是稳定了。不过writer还是在db02。那么先把db02 set_offline,在把db02 set_online,可以看到writer切换到了db01。


      有GC吗?呵呵,解决问题就好了 :-)


相关实践学习
如何在云端创建MySQL数据库
开始实验后,系统会自动创建一台自建MySQL的 源数据库 ECS 实例和一台 目标数据库 RDS。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心,利用清洁计算为万物互联的新世界提供源源不断的能源动力,目前开服的区域包括中国(华北、华东、华南、香港)、新加坡、美国(美东、美西)、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程,来了解阿里云能够为你的业务带来哪些帮助     相关的阿里云产品:云服务器ECS 云服务器 ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
目录
相关文章
|
6月前
|
存储 固态存储 关系型数据库
【MySQL技术内幕】2.5-Master Thread工作方式
【MySQL技术内幕】2.5-Master Thread工作方式
49 0
|
SQL 关系型数据库 MySQL
MySQL主从架构之Slave数据滞后Master怎么办?教你一招制敌!
MySQL主从架构之Slave数据滞后Master怎么办?教你一招制敌!
114 0
|
缓存 负载均衡 NoSQL
在阿里云Centos7.6上面配置Mysql主从数据库(master/slave),实现读写分离
在之前的一篇文章中,阐述了如何在高并发高负载的场景下使用nginx做后台服务的负载均衡:[在阿里云Centos上配置nginx+uwsgi+负载均衡配置](https://v3u.cn/a_id_77),但是不要以为这样做了就是一劳永逸的,到了数据业务层、数据访问层,如果还是传统的数据结构,或者只是单单靠一台服务器负载,如此多的数据库连接操作,数据库必然会崩溃,数据库如果宕机的话,后果更是不堪设想。这时候,我们会考虑如何减少数据库的连接,一方面采用优秀的代码框架,进行代码的优化,采用优秀的数据缓存技术如:redis,如果资金丰厚的话,必然会想到架设mysql服务集群,来分担主数据库的压力。今天
在阿里云Centos7.6上面配置Mysql主从数据库(master/slave),实现读写分离
|
关系型数据库 数据库 MySQL
|
SQL 监控 MySQL
MySQL · 源码分析 · change master to
重要数据结构 Rpl_info 的基类,保存了一些错误信息,如 IO/SQL thread last error class Slave_reporting_capability { // 获取last error Error const& last_error() const ...
1728 0
|
存储 关系型数据库 MySQL
|
关系型数据库 MySQL 数据库