主从数据库架构

在Web应用系统中,数据库性能是导致系统性能瓶颈最主要的原因之一。尤其是在大规模系统中,数据库集群已经成为必备的配置之一。集群的好处主要有:查询负载、数据库复制备份等。

MySQL数据库支持数据库的主从复制功能,因此在集群方面具有其独特的优势。众多国内外大型网站架构体系中,均采用了MySQL的主从数据库配置来实现查询负载、数据库热备等功能。本人在实际的Web项目中也涉及到这一需求,在此将如何配置实现做个简单小结。

1、实验环境

主库:Ubuntu  IP:192.168.1.189

从库:Ubuntu  IP:192.168.1.188

2、主数据库配置

A、修改配置文件/etc/mysql/my.cnf

任何一台MySQL数据库服务器都可以配置为集群主服务器,打开MySQL的配置文件,在配置文件中加入下面两行:

server-id = 1

log-bin = binlog_repl

binlog-do-db = test     //设置需要同步的数据库,如果需要设置多个,则加入多条这行语句。

注:MySQL是通过二进制的日志文件来进行主从数据库复制的,所以必须开启日志功能,即上述的log-bin;另外在集群中,每台数据库服务器都需要指定一个唯一ID,这里我们指定为1。

给主数据库授权一个可以进行复制的用户,执行如下命令:

grant replication slave on *.* to ‘slave‘@‘%‘ identified by ‘123‘;

执行成功后,重启MySQL。

B、锁定数据库并备份

mysql>flush tables with read lock;

备份数据库,传输到从数据库的数据目录下/var/lib/mysql;

C、用show master status;命令查看主数据库状态

+--------------------+----------+--------------+------------------+
       | File               | Position | Binlog_Do_DB | Binlog_Ignore_DB |
      +--------------------+----------+--------------+------------------+
       | binlog_repl.000001 |      106 | test         |                  |
      +--------------------+----------+--------------+------------------+

记录下File和Position的值。

D、主数据库解锁:unlock tables;

3、从数据库配置

A、修改配置文件/etc/mysql/my.cnf

在mysqld下加入如下代码:

server-id=2

master-host=192.168.1.189

master-user=slave

master-password=123

保存后,重启mysql服务。

B、设置slave参数,启动

在mysql下执行slave stop命令,停止slave服务;

mysql> change master to

-> master_host=‘192.168.1.189‘,

-> master_user=‘slave‘,

-> master_password=‘123‘,

-> master_log_file=‘binlog_repl.000001‘,

-> master_log_pos=106;

注意:这里的master_log_file,master_log_pos的值要和master的值一致。否则会无法同步。

执行slave start命令,启动服务。

4、验证同步

从数据库下运行show slave status \G;

如果能看到:

Slave_IO_Running: Yes

Slave_SQL_Running: Yes

说明已经成功启动了主从数据库的数据同步。

在主数据库中执行插入语句 insert into user values(‘kangqing‘,‘1234567890‘);

在从数据库中执行查询,可以看到主数据库插入的数据已经同步到从数据库表中。

本人在配置的时候出现过这样的问题:

Slave_IO_Running和Slave_SQL_Running的值都为Yes,但是无法和主数据库同步。在主数据库插入记录时,从数据库表无任何变化,执行show slave status时可以看到这样的错误:

Last_SQL_Error: Error ‘Table ‘user‘ is read only‘ on query. Default database: ‘test‘. Query: ‘insert into user values(‘gaga‘,‘5436897‘)‘

估计是权限问题。

解决方法:修改/var/lib/mysql文件夹的权限,对mysql.mysql用户赋予读写权限即可。

时间: 2024-08-10 02:10:09

主从数据库架构的相关文章

Mysql主从数据库架构的复制原理及配置详解

1 复制概述 Mysql内建的复制功能是构建大型,高性能应用程序的基础.将Mysql的数据分布到多个系统上去,这种分布的机制,是通过将Mysql的某一台主机的数据复制到其它主机(slaves)上,并重新执行一遍来实现的.复制过程中一个服务器充当主服务器,而一个或多个其它服务器充当从服务器.主服务器将更新写入二进制日志文件,并维护文件的一个索引以跟踪日志循环.这些日志可以记录发送到从服务器的更新.当一个从服务器连接主服务器时,它通知主服务器从服务器在日志中读取的最后一次成功更新的位置.从服务器接收

主从数据库架构配置

在Web应用系统中,数据库性能是导致系统性能瓶颈最主要的原因之一.尤其是在大规模系统中,数据库集群已经成为必备的配置之一.集群的好处主要有:查询负载.数据库复制备份等. MySQL数据库支持数据库的主从复制功能,因此在集群方面具有其独特的优势.众多国内外大型网站架构体系中,均采用了MySQL的主从数据库配置来实现 查询负载.数据库热备等功能.本人在实际的Web项目中也涉及到这一需求,在此将如何配置实现做个简单小结. 1.实验环境 主库:Ubuntu  IP:192.168.1.189 从库:Ub

MyCat 启蒙:分布式系统的数据库架构演变

MyCat是一个数据库分库分表中间件,使用MyCat可以非常方便地实现数据库的分库分表查询,并且减少项目中的业务代码.今天我们将通过数据库架构发展的演变来介绍MyCat的诞生背景,以及MyCat在其中扮演的角色,从而使得大家对MyCat的诞生及其作用有深入的理解. 单数据库架构 一个项目在初期的时候,为了尽可能快地验证市场,其对业务系统的最大要求是快速实现.在这个阶段,代码开发人员为了能快速实现业务系统,一般都是将所有层级(MVC)的业务代码都写在同一个项目中,所有的业务数据都存放在同一个数据库

MySQL主从数据库同步延迟问题解决(转)

最近在做MySQL主从数据库同步测试,发现了一些问题,其中主从同步延迟问题是其中之一,下面内容是从网上找到的一些讲解,记录下来以便自己学习: MySQL的主从同步是一个很成熟的架构,优点为:①在从服务器可以执行查询工作(即我们常说的读功能),降低主服务器压力;②在从主服务器进行备份,避免备份期间影响主服务器服务;③当主服务器出现问题时,可以切换到从服务器. MySQL主从同步故障-Slave_SQL_Running: No http://www.linuxidc.com/Linux/2014-0

直播平台的数据库架构演变

8月24日,阿里云数据库技术峰会到来,本次技术峰会邀请到了阿里集团和阿里云数据库老司机们,为大家分享了一线数据库实践经验和技术干货.在本次峰会上,特邀嘉宾映客直播架构师王振涛分享了映客直播作为创业公司从0至日活千万的数据库架构变迁,数据库在直播中的经典应用场景,数据库存储的优化思路,以及如何构建一个高可用数据库架构. 以下内容根据演讲嘉宾现场视频以及PPT整理而成. 本次分享的内容将主要围绕以下四个部分: 一.映客直播发展历程 二.直播遇上云数据库 三.风口上的数据库架构变迁 四.直播典型应用场

DB主从一致性架构优化4种方法

一.需求缘起 大部分互联网的业务都是"读多写少"的场景,数据库层面,读性能往往成为瓶颈.如下图:业界通常采用"一主多从,读写分离,冗余多个读库"的数据库架构来提升数据库的读性能. 这种架构的一个潜在缺点是,业务方有可能读取到并不是最新的旧数据: (1)系统先对DB-master进行了一个写操作,写主库 (2)很短的时间内并发进行了一个读操作,读从库,此时主从同步没有完成,故读取到了一个旧数据 (3)主从同步完成 有没有办法解决或者缓解这类"由于主从延时导致

优化网站性能之数据库架构篇

很多小型网站的开发人员一开始将注意力放在产品需求设计上,这本无可厚非.但如果忽视整体性能.可扩展性等方面的考虑,眼看着访问量一天天往上爬,可突然发现有一天网站因为访问量过大而崩溃了,到时候哭都来不及. 我在后端设计中曾经提到,对于高并发高访问的Web应用来说,数据库存取瓶颈一直是个令人头疼的问题.特别当你的程序架构还是建立在单数据库模式,而一个数据池连接数峰值已经达到500的时候,那你的程序运行离崩溃的边缘也不远了.在Web网站的规模从小到大不断扩展的过程中,数据库的架构也需要动态扩展,每一次扩

解决主从数据库同步延迟问题

场景:需要在主机写入之后,保证在备机一定能够读取到已经写入的数据,也就是需要主从架构下的强一致性. 主机与备机之间的物理延迟是不可控的,也是无法避免的.但是如果仅仅需要满足这种强一致性,是相对简单的事情:只需要在主机写入时,确认更新已经同步到备机之后,再返回写操作成功即可.主从数据库支持这种完全的同步模式. 不过一般不建议使用这种同步模式.显而易见,如果写操作必须等待更新同步完成,肯定会极大影响性能. 问题的关键在于,主从架构是一种用于数据容错的高可用性解决方案,而不是一种处理高并发压力的解决方

数据库架构设计思路

一 .58同城数据库架构设计思路 (1)可用性设计 解决思路:复制+冗余 副作用:复制+冗余一定会引发一致性问题 保证"读"高可用的方法:复制从库,冗余数据,如下图  带来的问题:主从不一致 解决方案:见下文 保证"写"高可用的一般方法:双主模式,即复制主库(很多公司用单master,此时无法保证写的可用性),冗余数据,如下图  带来的问题:双主同步key冲突,引不一致 解决方案: a)方案一:由数据库或者业务层保证key在两个主上不冲突 b)方案二:见下文 58同