mysql主从配置

mysqldump备份和恢复

那年仲夏 提交于 2020-02-16 18:57:55
一、备份单个数据库 1、备份命令:mysqldump   MySQL数据库自带的一个很好用的备份命令。是逻辑备份,导出 的是SQL语句。也就是把数据从MySQL库中以逻辑的SQL语句的形式直接输出或生成备份的文件的过程。 单实例语法(Syntax): mysqldump -u <username> -p <dbname> > /path/to/***.sql 多实例的备份语法(Syntax): mysqldump -u <username> -p <dbname> -S <sockPath> > /path/to/***.sql eg: mysqldump -u root -p wordpress > /opt/wordpress_$(date +%F).sql 2、参数解析 -A --all-databases:导出全部数据库 -Y --all-tablespaces:导出全部表空间 -y --no-tablespaces:不导出任何表空间信息 --add-drop-database每个数据库创建之前添加drop数据库语句。 --add-drop-table每个数据表创建之前添加drop数据表语句。(默认为打开状态,使用--skip-add-drop-table取消选项) --add-locks在每个表导出之前增加LOCK TABLES并且之后UNLOCK TABLE。

linux下MySQL安装

大城市里の小女人 提交于 2020-02-16 09:53:06
mysql 版本的区别 http://www.cnblogs.com/langtianya/p/5185601.html mysql 软件可以去官网下载 http://dev.mysql.com/downloads/mysql/ ,也可以去大公司的资源库下载,比如: http://mirrors.sohu.com/mysql/MySQL-5.7/ 这是搜狐的。 多实例创建方法 : http://blog.csdn.net/leshami/article/details/40339295 一、 mysql 二进制免编译包安装 mysql 二进制免编译安装 # cd /usr/local/src/ 约定以后安装软件就下载到这里使用 # wget http://mirrors.sohu.com/mysql/MySQL-5.5/mysql-5.5.51-linux2.6-x86_64.tar.gz 下载 # tar zxvf mysql-5.5.51-linux2.6-x86_64.tar.gz 解压 # mv mysql-5.5.51-linux2.6-x86_64 /usr/local/mysql 移动位置到安装目录下 # useradd -s /sbin/nologin mysql 建立 mysql 用户 # cd /usr/local/mysql 进入安装目录,目录下有许多文件。

MySQL复制(一)--复制概述

送分小仙女□ 提交于 2020-02-15 19:15:33
MySQL复制(replication)文档集合: 1.复制概述 2.基于二进制日志文件位置(binlog)配置复制 3.基于全局事物标识符(GTID)配置复制 4.多源复制 5.级联复制 6.半同步复制 7.延迟复制 8.复制过滤规则 9.对复制进行故障排除 10.故障切换 11.复制管理 (一)什么是复制 MySQL复制可以使数据从一台MySQL服务器(主服务器)复制到一台或多台MySQL服务器(从服务器),默认情况下,MySQL的复制是异步的,从服务器不需要永久连接就可以接收来自主服务器的更新。根据配置,可以对整个实例进行复制,也可以对单个db进行复制,还可以对某个表或多个表进行复制。 (二)复制的优点 MySQL复制的优点主要有: 横向扩展数据库。通过复制,将写业务放在主数据库上,将读业务放到从数据库上,分散业务负载,提高业务性能; 数据安全。主服务器发生crash,可以将从服务器切换为主服务器,减少宕机带来的损失; 实时数据分析。信息分析可以在从数据库上进行,而不会影响主数据库的性能。 (三)复制的方法(二进制日志文件位置和GTID) MySQL提供了基于二进制日志文件位置和GTID两种方法来配置复制。两种方法主要区别如下: 基于二进制日志文件位置的复制:是传统的复制方法。通过从库已经应用到的日志文件的位置(master_log_file,master_log_pos

Mysql + canal + zookeeper环境搭建

一世执手 提交于 2020-02-14 23:19:29
Mysql + canal + zookeeper环境搭建 一、mysql集群搭建 1. mysql基本环境 操作系统: Linux version 2.6.32-431.el6.x86_64 数据库:MySQL Community Server 5.7.20 主节点IP:10.60.81.157 主节点IP:10.60.81.158 从节点IP:10.60.81.159 2. 安装mysql 2.1.官网下载MySQL mysql-5.7.20-1.el6.x86_64.rpm-bundle.tar 2.2. 三个节点都安装: 2.2.1.三个节点查看是否安装mysql rpm -qa | grep mysql rpm -e --nodeps mysql-libs-5.1.66-2.el6_3.x86_64 (有则删除) 2.2.2. 三个节点都安装mysql tar –xvf mysql-5.7.20-1.el6.x86_64.rpm-bundle.tar rpm -ivh mysql-community-common-5.7.20-1.el6.x86_64.rpm rpm -ivh mysql-community-libs-5.7.20-1.el6.x86_64.rpm rpm -ivh mysql-community-client-5.7.20-1.el6.x86_64

MySQL开发规范与使用技巧总结

为君一笑 提交于 2020-02-13 20:23:52
1.命名规范 1.库名、表名、字段名必须使用小写字母,并采用下划线分割。 a)MySQL有配置参数lower_case_table_names,不可动态更改,linux系统默认为 0,即库表名以实际情况存储,大小写敏感。如果是1,以小写存储,大小写不敏感。如果是2,以实际情况存储,但以小写比较。 b)如果大小写混合使用,可能存在abc,Abc,ABC等多个表共存,容易导致混乱。 c)字段名显示区分大小写,但实际使⽤用不区分,即不可以建立两个名字一样但大小写不一样的字段。 d)为了统一规范, 库名、表名、字段名使用小写字母。 2.库名、表名、字段名禁止超过32个字符。 库名、表名、字段名支持最多64个字符,但为了统一规范、易于辨识以及减少传输量,禁止超过32个字符。 3.使用INNODB存储引擎。 INNODB引擎是MySQL5.5版本以后的默认引擘,支持事务、行级锁,有更好的数据恢复能力、更好的并发性能,同时对多核、大内存、SSD等硬件支持更好,支持数据热备份等,因此INNODB相比MyISAM有明显优势。 4.库名、表名、字段名禁止使用MySQL保留字。 当库名、表名、字段名等属性含有保留字时,SQL语句必须用反引号引用属性名称,这将使得SQL语句书写、SHELL脚本中变量的转义等变得⾮非常复杂。 5.禁止使用分区表。 分区表对分区键有严格要求;分区表在表变大后,执⾏行DDL

MYSQL高可用——MHA(概述与安装)

陌路散爱 提交于 2020-02-13 20:18:43
MHA(Master High Availability)目前在MySQL高可用方面是一个相对成熟的解决方案,它由日本DeNA公司youshimaton(现就职于Facebook公司)开发,是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件。在MySQL故障切换过程中,MHA能做到在0~30秒之内自动完成数据库的故障切换操作,并且在进行故障切换的过程中,MHA能在最大程度上保证数据的一致性,以达到真正意义上的高可用。 github地址: https://github.com/yoshinorim **该软件由两部分组成:MHA Manager(管理节点)和MHA Node(数据节点)。**MHA Manager可以单独部署在一台独立的机器上管理多个master-slave集群,也可以部署在一台slave节点上。MHA Node运行在每台MySQL服务器上,MHA Manager会定时探测集群中的master节点,当master出现故障时,它可以自动将最新数据的slave提升为新的master,然后将所有其他的slave重新指向新的master。整个故障转移过程对应用程序完全透明。 ​ 在MHA自动故障切换过程中,MHA试图从宕机的主服务器上保存二进制日志,最大程度的保证数据的不丢失,但这并不总是可行的。例如,如果主服务器硬件故障或无法通过ssh访问

MySQL数据库备份与恢复

断了今生、忘了曾经 提交于 2020-02-13 01:05:15
MySQL数据库备份与恢复 1、备份方式 逻辑备份(文本表示:SQL 语句) 物理备份(数据文件的二进制副本) 基于快照的备份 基于复制的备份 增量备份(刷新二进制日志) 2、备份类型 2.1 热备份 这些动态备份在读取或修改数据的过程中进行,很少中断或者不中断传输或处理数据的功能。使用热备份时,系统仍可供读取和修改数据的操作访问。 2.2冷备份 这些备份在用户不能访问数据时进行,因此无法读取或修改数据。这些脱机备份会阻止执行任何使用数据的活动。这些类型的备份不会干扰正常运行的系统的性能。但是,对于某些应用程序,会无法接受必须在一段较长的时间里锁定或完全阻止用户访问数据。 2.3温备份 这些备份在读取数据时进行,但在多数情况下,在进行备份时不能修改数据本身。这种中途备份类型的优点是不必完全锁定最终用户。但是,其不足之处在于无法在进行备份时修改数据集,这可能使这种类型的备份不适用于某些应用程序。在备份过程中无法修改数据可能产生性能问题。 3、物理备份 物理备份由存储数据库内容的目录和文件的原始副本组成。这种类型的备份适用于需要在发生问题时快速恢复的大型重要数据库。 3.1物理备份的特点 备份由数据库目录和文件的精确副本组成。通常这是全部或部分MySQL数据目录的副本。 物理备份方法比逻辑更快,因为它们只涉及文件复制而无需转换。 输出比逻辑备份更紧凑。 由于备份速度和紧凑性对繁忙

mysql、oracle分库分表方案之sharding-jdbc使用(非demo示例)

风流意气都作罢 提交于 2020-02-12 06:25:21
选择开源核心组件的一个非常重要的考虑通常是社区活跃性,一旦项目团队无法进行自己后续维护和扩展的情况下更是如此。 至于为什么选择sharding-jdbc而不是Mycat,可以参考知乎讨论帖子https://www.zhihu.com/question/64709787。 还可以参考https://blog.csdn.net/u013898617/article/details/79615427。 关于分库分表和读写分离、主从 一般来说,需要分库分表的系统是流量比较大的,而且比较容易出现峰值的比如说打折/活动的时候;其次,当单机扛不住业务流量的时候,分库分表一定不是第一选择,在分库分表之前,应该先保证垂直拆分完成了,子系统内都是高内聚的,其次基于Master-Slave的读写分离或者模糊查询很多的,可能NoSQL比如elastic就引流去很大一部分了。当读写分离也做完了,主库只剩下关键业务逻辑之后,流量还是很高,这个时候才开始考虑分库分表。因为相对于读写分离、垂直拆分,分库分表对开发和运维的要求多得多,如果确定业务一两年内不会剧增的,盲目引入只会导致成本高昂(尤其是各种SQL限制)。 其次,分库分表会增加N倍的数据库服务器,一般来说是4的倍数,如果某个应用说要做分库分表,又只有两台机器,那完全就是凑热闹。 读写分离和分库分表应该来说是前后的两件事比较合理

MySQL经典面试题

爱⌒轻易说出口 提交于 2020-02-12 04:24:22
MySQL经典面试题 1、MySQL的复制原理以及流程 (1)、复制基本原理流程 1. 主:binlog线程——记录下所有改变了数据库数据的语句,放进master上的binlog中; 2. 从:io线程——在使用start slave 之后,负责从master上拉取 binlog 内容,放进 自己的relay log中; 3. 从:sql执行线程——执行relay log中的语句; (2)、MySQL复制的线程有几个及之间的关联 MySQL 的复制是基于如下 3 个线程的交互( 多线程复制里面应该是 4 类线程): 1. Master 上面的 binlog dump 线程,该线程负责将 master 的 binlog event 传到slave; 2. Slave 上面的 IO 线程,该线程负责接收 Master 传过来的 binlog,并写入 relay log; 3. Slave 上面的 SQL 线程,该线程负责读取 relay log 并执行; 4. 如果是多线程复制,无论是 5.6 库级别的假多线程还是 MariaDB 或者 5.7 的真正的多线程复制, SQL 线程只做 coordinator,只负责把 relay log 中的 binlog读出来然后交给 worker 线程, woker 线程负责具体 binlog event 的执行; (3)

MySQL经典面试题

孤人 提交于 2020-02-12 03:49:55
MySQL经典面试题 1、MySQL的复制原理以及流程 (1)、复制基本原理流程 1. 主:binlog线程——记录下所有改变了数据库数据的语句,放进master上的binlog中; 2. 从:io线程——在使用start slave 之后,负责从master上拉取 binlog 内容,放进 自己的relay log中; 3. 从:sql执行线程——执行relay log中的语句; (2)、MySQL复制的线程有几个及之间的关联 MySQL 的复制是基于如下 3 个线程的交互( 多线程复制里面应该是 4 类线程): 1. Master 上面的 binlog dump 线程,该线程负责将 master 的 binlog event 传到slave; 2. Slave 上面的 IO 线程,该线程负责接收 Master 传过来的 binlog,并写入 relay log; 3. Slave 上面的 SQL 线程,该线程负责读取 relay log 并执行; 4. 如果是多线程复制,无论是 5.6 库级别的假多线程还是 MariaDB 或者 5.7 的真正的多线程复制, SQL 线程只做 coordinator,只负责把 relay log 中的 binlog读出来然后交给 worker 线程, woker 线程负责具体 binlog event 的执行; (3)