常见现象 运维工作中会经常维护MySQL主从服务器,当然Slave我们只是用于读操作. 一般权限开通也只授权只读账号,但是有时候维护工作可能不是一个人在做,你不能保证其他同事都按照这个标准操作. 有同事可能会授权Slave库MySQL账号为all或者select,update,insert,delete.还有一种情况是主从做了对所有数据的同步(包括用户信息),在Master库上面授权的账号也同步到了Slave库上面,当然Master账号中肯定会有select,update,insert,dele

结构图如下: Postgresql早在9.0版本开始支持物理复制,也称为流复制,通过从实例级复制出一个与主库一模一样的备库.流复制同步方式有同步,异步两种,如果主节点和备节点不是很忙,通常异步模式下备库和主库的延迟时间能够控制在毫秒级.物理复制只能复制整个实例. 逻辑复制也成为选择性复制,可以做到基于表级别的复制,选择需要逻辑复制的表,而不是复制实例上的所有数据库的表,10版本不支持内置的逻辑复制,通常使用第三方逻辑复制. WAL日志记录数据库变化,格式为二级制格式,尽管流复制都是基于WAL,但

  演练包括被动切换和主动切换两部分.被动切换是主库宕机,主动切换是人工手动触发.   演练步骤大致如下:       1 先停掉主库,模拟主库宕机     2 mha将vip切到备库,备库变成主库,应用可以正常读写数据库     3 重新启动宕机的原主库     4 在原主库上建立同步关系(根据宕机时,日志记录的binlog的文件名和偏移量,恢复从这里开始)     5 mha手动切换主库,还原到最初状态,应用可以正常读写数据库     6 演练结束     演练过程问题总结:   1 mha

MySQL设置了主从复制,为保证数据一致性需要在从库设置只读状态 查看默认读写状态 show global variables like "%read_only%"; 设置只读 #设置只读(一个是普通用户设置只读一个是超级用户设置只读) set global read_only=1; set global super_read_only=1; 创建一个库查看是否设置成功 提示无法创建 主从复制不受影响,可正常写入 如果在做数据恢复的时候希望从库也无法进行任何写入需要锁表 #锁表 flu

golang github.com/go-sql-driver/mysql 遇到的数据库,设置库设计不合理的解决方法,查询中报了以下这个错 Scan error on column index 2: unsupported Scan, storing driver.Value type <nil> 解决方案就是动态的把数据 字段前加一上一个COALESCE SELECT u.id,ta.`title` as `活动名` ,COALESCE(IFNULL(i.name,i.nickname) F

最近线上频繁的出现slave延时的情况,经排查发现为用户在删除数据的时候,由于表主键的主键的缺少,同时删除条件没有索引,或或者删除的条件过滤性极差,导致slave出现hang住,严重的影响了生产环境的稳定性,也希望通过这篇博客,来加深主键在innodb引擎中的重要性,希望用户在使用RDS,设计自己的表的时候,一定要为表加上主键,主键可以认为是innodb存储引擎的生命,下面我们就来分析一下这个案例(本案例的生产环境的binlog为row模式,对于myisam存储引擎也有同样的问题):(1).现象

window下mysql创建库只读和启动失败都有可能是my.ini配置文件出错的问题 遇到如下错误ERROR 1036 (HY000): Table 'schemata' is read only,办法是修改my.ini文件 my.ini文件在安装的mysql下,我删除了多余的项,就能解决 我的mu.ini配置如下 [mysqld] port basedir="E:/Develop/mysql/" datadir="E:/Develop/mysql/data/" c

主从复制条件: Mysql 单机多实例安装参考Mysql 5.7.21 设置主从库同步 下面的操作是多实例主从复制,3306为主库,3307为从库. 主库要开启log-bin,主库和从库的server-id要不一样,修改/etc/my.cnf配置 [mysqld_multi] mysqld = /usr/local/mysql/bin/mysqld mysqladmin = /usr/local/mysql/bin/mysqladmin log = /tmp/mysql_multi.log us

先要修改配置文件,重启mysql服务 log-bin= mysql-binlog # 打开二进制日志 ,最好放在不同的硬盘上,减小 IO 消耗 expire_logs_day= # 设置二进制日志保存日期 max_binlog_size=500M # 设置 每个 binlog 文件的大小 1.创建复制用户 CREATE USER '; 2.权限授予 GRANT REPLICATION SLAVE ON *.* TO 'rep_user'@'%.192.168.0.106'; 3.备份主库 C:\

最近线上频繁的出现slave延时的情况,经排查发现为用户在删除数据的时候,由于表主键的主键的缺少,同时删除条件没有索引,或或者删除的条件过滤性极差,导致slave出现hang住,严重的影响了生产环境的稳定性,也希望通过这篇博客,来加深主键在innodb引擎中的重要性,希望用户在使用RDS,设计自己的表的时候,一定要为表加上主键,主键可以认为是innodb存储引擎的生命,下面我们就来分析一下这个案例(本案例的生产环境的binlog为row模式,对于myisam存储引擎也有同样的问题):(1).现象

背景 在mysql主备环境下,主备同步过程如下,主库更新产生binlog, 备库io线程拉取主库binlog生成relay log.备库sql线程执行relay log从而保持和主库同步. 理论上主库有更新时,备库都存在延迟,且延迟时间为备库执行时间+网络传输时间即t4-t2. 那么mysql是怎么来计算备库延迟的? 先来看show slave status中的一些信息,io线程拉取主库binlog的位置: Master_Log_File: mysql-bin.000001 Read_Maste

DG搭建时,官方文档手册有明确提到要设置数据库为force_logging,防止有nologging操作日志记录不全导致备库应用时出现问题. 虽然是老生常谈的安装规范,但现实中总会遇到不遵守规范的场景,最近就在某客户现场遇到一则这样的案例,因为DG主库设置force_logging晚于DG搭建,导致备库出现坏块,使用dbv检查就表现为DBV-201错误. 下面我们来模拟下这个场景,同时演示下具体修复过程: 1.准备实验环境 2.构造故障场景 3.解决故障 1.准备实验环境 主库确认没有开启for

原文链接:http://blog.sina.com.cn/s/blog_64e166580100xks5.html 如何正确地删除Archivelog: Archivelog并不能直接得从OS层直接物理删除,因为archivelog的相关信息是记录在controlfile中的,当物理删除后不会改变controlfile的设置.并且在查询相关的动态视图(例如v$archived_log)时,该部分日志仍然标注为存在.也就是说Oracle并不认为这些日志被删除了,所以在删除archivelog的时候

前言: MySQL 主从架构应该是最常用的一组架构了.从库会实时同步主库传输来的数据,一般从库可以作为备用节点或作查询使用.其实不只是主库需要多关注,从库有时候也要经常维护,本篇文章将会分享几点从库维护经验,一起来学习吧. 1.主从复制建议采用 GTID 模式 GTID 即全局事务 ID(Global Transaction ID),GTID 实际上是由 server_uuid:transaction_id 组成的.其中 server_uuid 是一个 MySQL 实例的唯一标识, transa

互联网网站应用大多采用mysql作为DB存储,限于mysql单机性能的瓶颈,为了支撑更大容量和更大的访问量,dba一般通过建立分布式集群,让多个mysql共同提供服务.所谓的mysql分布式集群,实质就是将原有的数据拆成多份,放在多个mysql数据库上存储,应用通过中间层路由到对应的数据库分片,访问所需要数据,基本架构如图1所示.这里的关键点就是“拆”,如何拆库,根据业务场景,一般可以采取水平拆分和垂直拆分.所谓水平拆分是指,将一个大表按一定的规则分片,分布在多个mysql数据库中:垂直拆分则是

我们知道Oracle有DataGuard实时备份数据.能够做主备切换,而MySQL也有自己的一套备库方案.称之为主从复制. 搭建MySQL从库是为了实时同步主库数据,同一时候也能够分担主库的读压力.对数据库端做成读写分离结构. 搭建MySQL主从库注意点: 1.主库和从库的 server-id 一定不能同样. 2.在主库创建replication slave账户. grant replication slave on *.* to 'repl'@'192.168.0.232' identifie

http://www.osyunwei.com/archives/7464.html (学习运维知识好站) 说明: 操作系统:CentOS 5.X 64位 MySQL主服务器:192.168.21.126 MySQL从服务器:192.168.21.127,192.168.21.128 MySQL主从同步的数据库为:osyunweidb 实现目的: 增加两台服务器(主备),通过LVS+Keepalived实现MySQL从库读操作负载均衡 架构规划: 操作系统:CentOS 5.X 64位 LVS主

[20170825]11G备库启用DRCP连接3.txt --//昨天测试了11G备库启用DRCP连接,要设置alter system set audit_trail=none scope=spfile ; --//参考链接http://blog.itpub.net/267265/viewspace-2144036/.--//在测试过程中我遇到1个奇怪问题,就是如果主库没有打开drcp,备库执行exec dbms_connection_pool.start_pool();失败.--//今天分析看

[20170824]11G备库启用DRCP连接.txt --//参考链接:http://blog.itpub.net/267265/viewspace-2099397/blogs.oracle.com/database4cn/adg%e5%a4%87%e5%ba%93%e7%9a%84drcp%e8%bf%9e%e6%8e%a5%e6%8a%a5%e9%94%99oci-21500%e8%a7%a3%e5%86%b3%e4%b8%80%e4%be%8b 1.测试环境: SYS@bookdg> s

转载于osyunwei 说明: 操作系统:CentOS 5.X 64位 MySQL主服务器:192.168.21.126 MySQL从服务器:192.168.21.127,192.168.21.128 MySQL主从同步的数据库为:osyunweidb 实现目的: 增加两台服务器(主备),通过LVS+Keepalived实现MySQL从库读操作负载均衡 架构规划: 操作系统:CentOS 5.X 64位 LVS主服务器:192.168.21.129 LVS备服务器:192.168.21.130

1.转载:https://blog.csdn.net/zfl589778/article/details/51441719/ 2.效果:亲测有效,数据写入成功. 3.主机宕机后,如果不是长时间宕机,且可手动重启,直接重启即可,[从]数据库数据会进行写入,无需重新配置my.cnf.[这里的主机宕机方案指的是:主机很长时间无法启动] 4.原理:MySQL从库上有一个IO线程负责从主库取binlog写到本地,另外有一个SQL线程负责执行这些本地值日,实现命令重做 5.步骤: 一.准备工作 系统:Cen