MySQL 8.0 InnoDB Cluster 恢复故障成员

InnoDB Cluster 一节点丢失

初始化故障节点

systemctl stop mysqld
rm -rf /var/lib/mysql/*
systemctl start mysqld

导出正常节点的数据库,并传到故障节点

mysqldump --all-databases --triggers --routines --events --quick --single-transaction --flush-logs --master-data=2 > dbs.dump
scp dbs.dump 192.168.1.224:~/

故障节点导入数据库

mysql> set sql_log_bin=0;
mysql> ALTER USER [email protected]‘localhost‘ IDENTIFIED BY ‘MySQL8.0‘;
mysql> source dbs.dump
mysql> set sql_log_bin=1;

重启故障节点 MySQL

systemctl restart mysqld

将故障节点重新加入集群

MySQL  192.168.1.226:33060+ ssl  JS > var cluster=dba.getCluster(‘appCluster‘)
MySQL  192.168.1.226:33060+ ssl  JS > cluster.removeInstance(‘[email protected]:3306‘)
MySQL  192.168.1.226:33060+ ssl  JS > cluster.addInstance(‘[email protected]:3306‘)

集群恢复正常

 MySQL  192.168.1.226:33060+ ssl  JS > cluster.status()
{
    "clusterName": "appCluster",
    "defaultReplicaSet": {
        "name": "default",
        "primary": "192.168.1.226:3306",
        "ssl": "REQUIRED",
        "status": "OK",
        "statusText": "Cluster is ONLINE and can tolerate up to ONE failure.",
        "topology": {
            "192.168.1.224:3306": {
                "address": "192.168.1.224:3306",
                "mode": "R/O",
                "readReplicas": {},
                "role": "HA",
                "status": "ONLINE"
            },
            "192.168.1.225:3306": {
                "address": "192.168.1.225:3306",
                "mode": "R/O",
                "readReplicas": {},
                "role": "HA",
                "status": "ONLINE"
            },
            "192.168.1.226:3306": {
                "address": "192.168.1.226:3306",
                "mode": "R/W",
                "readReplicas": {},
                "role": "HA",
                "status": "ONLINE"
            }
        }
    },
    "groupInformationSourceMember": "mysql://[email protected]:3306"
}

原文地址:http://blog.51cto.com/linux10000/2177488

时间: 2024-11-10 07:49:38

MySQL 8.0 InnoDB Cluster 恢复故障成员的相关文章

MySQL · 引擎特性 · InnoDB 崩溃恢复过程

MySQL · 引擎特性 · InnoDB 崩溃恢复过程 在前面两期月报中,我们详细介绍了 InnoDB redo log 和 undo log 的相关知识,本文将介绍 InnoDB 在崩溃恢复时的主要流程. 本文代码分析基于 MySQL 5.7.7-RC 版本,函数入口为 innobase_start_or_create_for_mysql,这是一个非常冗长的函数,本文只涉及和崩溃恢复相关的代码. 在阅读本文前,强烈建议翻阅我们之前的两期月报:1. MySQL · 引擎特性 · InnoDB

mysql 使用 Forcing InnoDB Recovery 恢复数据库

环境: CentOS release 6.6 (Final) Server version: 5.5.42-37.1-log Percona Server (GPL), Release 37.1, Revision 39acee0 现象: 数据库挂掉,重启报错 The server quit without updating PID file (/var/lib/mysql/cm.data.dingkai.com.pid).[失败] 日志: 150721 12:38:37  InnoDB: Da

MySQL 8.0.11 innodb cluster 运维管理手册之四-msyqlbackup备份

MySQL 8.0.11 innodb cluster 运维管理手册之四-msyqlbackup备份 作者 方连超 Mysqlbackup 介绍 mysqlbackup是一个热备份工具.也就是说它不像mysqldump那样给表上一个全局锁,由于mysqldump上了这个锁,所以就造成客户端只能对数据库进行读操作不能写,这也就是称mysqldump为温备份的原因.但是mysqlbackup真的有这么吊吗?答案是并没有.对于innodb引擎的表mysqlbackup 热备的:但是对于非innodb表

MySQL 8.0.11 innodb cluster 运维管理手册之二--集群搭建

MySQL 8.0.11 innodb cluster 高可用集群部署运维管理手册之二 集群建设 作者 方连超 基础环境 系统:centos 7.5Mysql:8.0.11 二进制包Mysqlshell: 8.0.11 rpm 包Mysql router: 8.0.11 二进制包 架构: 192.168.181.101 myrouter1 Keepalived.MySQL-shell.MySQL-Router.MySQL-client 192.168.181.102 myrouter2 Keep

Mysql Innodb Cluster测试

本文介绍mysql 8版本下的Innodb Cluster配置与测试过程,其核心还是mysql的组复制功能,通过使用mysql shell简化了组复制的配置过程,同时使用mysql route中间件实现了故障的自动转移以及读写分离等功能.之前测试mysql组复制的时候有提出过中间件的问题,mysql-route是个不错的解决方案,前文传送门:http://blog.51cto.com/ylw6006/1976829 一.环境介绍 操作系统:centos linux 7.2 64bitmysql社

mysql innodb cluster 搭建

根据文档搭建...https://dev.mysql.com/doc/refman/8.0/en/mysql-innodb-cluster-production-deployment.html 环境准备:1 下载和安装需要的软件(本人的软件版本--都是mysql Community中的Linux Generic版本)mysql-server(mysql-8.0.17-linux-glibc2.12-x86_64.tar.xz)mysql-router(mysql-router-8.0.17-li

MySQL系列:innodb源码分析之redo log恢复

在上一篇<innodb源码分析之重做日志结构>中我们知道redo log的基本结构和日志写入步骤,那么redo log是怎么进行数据恢复的呢?在什么时候进行redo log的日志推演呢?redo log的推演只有在数据库异常或者关闭后,数据库重新启动时会进行日志推演,将数据库状态恢复到关闭前的状态.那么这个过程是怎么进行的呢?以下我们逐步来解析. 1.recv_sys_t结构 innodb在MySQL启动的时候,会对重做日志文件进行日志重做,重做日志是通过一个recv_sys_t的结构来进行数

MySQL 8.0.2复制新特性(翻译)

译者:知数堂星耀队 MySQL 8.0.2复制新特性 MySQL 8 正在变得原来越好,而且这也在我们MySQL复制研发团队引起了一阵热潮.我们一直致力于全面提升MySQL复制,通过引入新的和一些有趣的功能.此外,我们还听取了社区的建议和反馈.因此,我们很荣幸能够与你一同见证最新版本(MySQL 8.0.2)的里程碑式的发布,为此我们总结了其中的一些值得注意的变化.跟随我们下面的博客,我们将会分享这些新功能的一些见解. 我们对MySQL 组复制进行了加强,主要有以下几个方面: 不允许对离开组的成

MySQL &#183; 引擎特性 &#183; InnoDB redo log漫游(转)

前言 InnoDB 有两块非常重要的日志,一个是undo log,另外一个是redo log,前者用来保证事务的原子性以及InnoDB的MVCC,后者用来保证事务的持久性. 和大多数关系型数据库一样,InnoDB记录了对数据文件的物理更改,并保证总是日志先行,也就是所谓的WAL,即在持久化数据文件前,保证之前的redo日志已经写到磁盘. LSN(log sequence number) 用于记录日志序号,它是一个不断递增的 unsigned long long 类型整数.在 InnoDB 的日志