网站MySQL数据库优化方案-主从架构及读写分离

网站MySQL数据库优化方案

网络运维信息管理中心

（2020年8月）

数据库为网站提供数据的结构化存储，是网站系统的重要组成部分，但随着业务逻辑的复杂度的增加，数据库需要不断的优化,单一的数据库已无法满足现在要求。

1.1优化目标

针对网站的MySQL数据库部署架构进行优化，其优化的目的是为了防止数据库出现单点故障问题，提高数据库的处理能力，提高数据库的可靠性，为保证网站业务正常办理。

1.2优化工作思路

1、对现有数据库现状分析包括现有数据库配置合理性分析、现有数据库部署情况两部分工作内容；

2、梳理现有网站的功能模块，目的是通过梳理网站的各功能模块对数据读取时效性，分析其是否可以实现读写；

3、以数据库主从架构及数据库读写分离方式，对网站的MySQL 数据库提出数据库部署架构优化的方案，数据库主从架构的多数据库模式，解决数据库单点存在的问题，当主数据库出现宕机时，可以将从数据库代替主数据库恢复业务系统正常运行，而且避免数据的丢失，提高数据库高可靠性和高可用性；通过部分查询统计功能，实现数据库读写分离，以便对数据库负载进行分流，缓解主数据库的读取压力。

2.1当前数据库部署架构图

当前网站的数据库采用单台MySQL数据库提供数据库服务，当前部署架构图如下：

2.2现有数据库主要配置梳理

2.3数据库部署情况梳理

2.3.1数据库安装部署情况梳理

2.3.2现有应用连接数据库情况梳理

连接数据库的应用系统有会员管理、权限管理、订单模块、商品管理、促销管理、广告管理、报表统计、文章管理、评论管理、系统设置、数据库管理、短信管理、推荐管理、邮件群发管理等。2.3.3数据库服务启动、停止方式梳理

1、启动命令

（1）普通启动：/data/soa/mysql/bin/mysqld

（2）centos6以前版本：service start mysqld

（3）centos7+：systemctl mysqld start

2、重启命令

先停止：killall mysqld

后启动：/data/soa/mysql/bin/mysqld

centos6以前版本：service restart mysqld

centos7+：systemctl mysqld restart

3、停止命令

killall mysqld 或 killall -9 mysqld

centos6以前版本：service stop mysqld

centos7+：systemctl mysqld stop

2.4数据库主机配置及运行情况

2.4.1数据库主机硬件配置及操作系统

2.4.2数据库主机资源使用情况

2.5现有使用数据库的功能模块

2.5.1当前技术开发架构

网站采用springboot2的开发框架，springboot2 是基于Java

语言的极速 web 开发框架，其核心设计目标是开发迅速、代码量少、学习简单、功能强大、轻量级、易扩展、Restful。springboot2 同时支持多数据源，并且可以针对这多个数据源配置独立的缓存、事务级别等。

2.5.2现有功能模块梳理

3数据库优化方案设计3.1数据库配置优化

3.2数据库主从架构设计

3.2.1网站当前数据库部署架构

1、当前数据库部署架构图

2、当前数据库部署架构存在问题及优化思路

通过当前数据库部署架构图可知，网站的数据库采用单台数据库。当数据库出现故障时，整个网站系统无法正常使用，影响系统正常运行，即网站的数据库存在单点故障；而且数据库服务器资源无法满足增长的读写请求。

针对网站的数据库架构进行优化，优化思路是增加数据库数量，实现数据库主从架构，其优化的目的是为了防止数据库出现单点故障问题，提高数据库的处理能力，提高数据库的可靠性，为保证网站业务正常办理。

3.2.2数据库主从架构优势

1、什么是数据库主从架构

MySQL数据库主从架构，是通过主从复制方式，让一个数据库与其他的数据库同步，保持两个或多个数据库的数据一致。

2、数据库主从架构与单一数据库比较

3、数据库主从架构优点

（1）数据分布：MySQL复制通常不会对带宽造成很大的压力，并且可以随意的停止或开始复制，并在不同的地理位置来分布数据

备份，例如不同的数据中心。即使在不稳定的网络环境下，远程复制也是可以工作。但如果为了保持很低的复制延迟，最好有一个稳定的、低延迟的连接。

（2）负载均衡：通过MySQL复制可以将读操作分不到多个服务器上，实现对读密集型应用的优化，并且实现很方面，通过简单的代码修改就能实现基本的负载均衡。对于小规模的应用，可以简单对机器，名做硬编码或使用DNS轮询。当然也可以使用更复杂的方法，例如网络负载均衡这一类的标准负载均衡解决方案。能够很好的将负载均衡分配到不同的MySQL服务器上。

（3）备份：对于备份来说，复制是一项很有意义的技术补充，但复制既不是备份也不能取代备份。

（4）高可用性和故障切换：复制能够补助应用程序避免MySQL 单点失败，一个包含复制的设计良好的故障切换系统能显著缩短当机时间。

（5）MySQL升级测试：这种做法比较普遍，使用一个更高版本的mysql作为备库，保证在升级全部实例前，查询能够在备库按照预期执行。

4、优化后的网站数据库部署架构

（1）数据库主从架构图

2、数据库主从架构说明

将主数据库与从数据库配置为主从同步模式，主数据库负责写入状态，从数据库将同步到主数据库刚写入的数据，保证从数据库与主数据库的数据一致。

优点是实时灾备，当主库出现问题，可以快速切换到从库提供服务；同时该架构容易扩展，比如实现读写分离，提高系统读写数据的性能，缓解数据库的压力，增加了数据库的处理能力。

3.2.3数据库主从架构实现原理

1、数据库主从实现架构图

2、数据库主从实现架构说明

（1）数据库主从实现整体有三个步骤

第一步：主数据库将改变记录到二进制日志(binary log)中（这些记录叫做二进制日志事件，binary log events）；

第二步：从数据库将主数据库的binary log events拷贝到它的中继日志(relay log)；

第三步：从数据库重做中继日志中的事件，将改变反映它自己的数据。

（2）数据库主从架构具体实现过程

第一部分就是主数据库记录二进制日志。在每个事务更新数据完成之前，主数据库在二日志记录这些改变。MySQL将事务串行的写入二进制日志，即使事务中的语句都是交叉执行的。在事件写入二进制日志完成后，主数据库通知存储引擎提交事务。

下一步就是从数据库将主数据库的binary log拷贝到它自己的中继日志。首先，从数据库开始一个工作线程——I/O线程。I/O线程在主数据库上打开一个普通的连接，然后开始binlog dump process。Binlog dump process从主数据库的二进制日志中读取事件，如果主数据库没有新的binary log记录，它会睡眠并等待主数据库产生新的事件。I/O线程将这些事件写入中继日志。

从数据库SQL线程（SQL thread）处理该过程的最后一步。SQL 线程从中继日志读取事件，并重放其中的事件而更新从数据库的数据，使其与主数据库中的数据一致。只要该线程与I/O线程保持一致，中继日志通常会位于OS的缓存中，所以中继日志的开销很小。

此外，在主数据库中也有一个工作线程：和其它MySQL的连接一样，从数据库在主数据库中打开一个连接也会使得主数据库开始一个线程。复制过程有一个很重要的限制——复制在从数据库上是串行化的，也就是说主数据库上的并行更新操作不能在从数据库上并行操作。

3.2.4数据库主从架构搭建的硬件要求

1、数据库主机数量

主数据库和从数据库部署建议在不同的主机上，这样实现一主一从的架构，需要两台数据库主机，目的是主数据库出现故障时，切换到从数据库继续提高数据库服务。

2、CPU要求

CPU尽量选择64位CPU，这样才可以安装64位操作系统，有了64位操作系统才能利用好更大的内存，便于后期服务器硬件扩展。

3、内存要求

内存IO高于SSD的IO，SSD的IO高于磁盘IO，足够的内存满足读请求与写请求，在选择内存时，要虑数据库并发量、数据库热数据的大小等。

4、硬盘要求

数据库的数据硬盘最好与操作系统的系统硬盘分开，目的是提高数据库I/O性能和保证数据安全，原因是系统盘使用频率（I/O）较高，而且操作系统最容易出现问题，在修复或重新安装操作系统时，容易将系统盘数据丢失。

3.2.5主数据库搭建流程

1、修改MySQL数据库配置文件https://www.wendangku.net/doc/1a3622148.html,f，配置一台数据库为主数据库，在MySQL数据库配置文件添加MySQL服务器id标识和开启二进制日志（binary log）功能，配置如下：

[mysqld]

log-bin=mysql-bin

server-id=1

参数说明如下：

2、修改完配置文件后，重启MySQL数据库服务。

3、主数据库上创建复制账号，通过SQL语句创建，SQL语句如下：

mysql> GRANT REPLICATION SLAVE ON *.* to 'replication'@'%' identified by '123456';

4、查询主数据库状态，查看主数据库状态SQL语句为：

mysql> show master status;

比如如下结果如下：

记录主数据库的两个关键数值File和Position，两个字段说明如下：

执行完此步骤后不要再操作主数据库，防止主服务器状态值变化。

5、通过MySQL的mysqldump命令进行对需要做主从同步的库进行备份，命令如下：

mysqldump -u root -p --lock-tables -R -q --databases --extended-insert=true --default-character-set=utf8 数据库名 > 数据库名.sql

mysqldump参数说明：

6、将mysqldump备份出来的备份文件“数据库名.sql”复制到从数据库服务器上。

3.2.6从数据库搭建流程

1、修改MySQL从数据库配置文件https://www.wendangku.net/doc/1a3622148.html,f，增加 server-id参数，配置参数如下：

[mysqld]

server-id=2

参数说明如下：

2、从数据库配置修改完后，使用 - -skip-slave- start选项启动从数据库,这样不会立即启动从数据库服务上的复制进程,方便我们对从数据库的服务进行进一步的配置，操作命令：

mysql> mysqld_safe --defaults-file=/etc/https://www.wendangku.net/doc/1a3622148.html,f --skip-slave-start

注：此示例的https://www.wendangku.net/doc/1a3622148.html,f路径只做参考，具体实施时按实际路径填写。

3、对从数据库做相应设置,指定复制使用的用户、密码，主数据库服务器的IP、端口，以及开始执行复制的日志文件和位置等,执行SQL语句如下:

mysql> CHANGE MASTER TO MASTER_HOST='192.168.xxx.xxx',MASTER_PORT=3306,MASTER_USER ='replication',MASTER_PASSWORD='123456' ,MASTER_LOG_FILE=' mysql-bin.000004',MASTER_LOG_POS=308;

SQL语句参数说明：

4、启动从数据库复制功能,执行SQL语句如下:

mysql> start slave;

5、检查从服务器复制功能状态,执行SQL语句如下:

mysql> show slave status\G

********************** 1. row ********************* Slave_IO_State: Waiting for master to send event

Master_Host: 192.168.xxx.xxx//主服务器地址

Master_User: 'replication' //授权帐户名，尽量避免使用root

Master_Port: 3306 //数据库端口，部分版本没有此行

Connect_Retry: 60

Master_Log_File: mysql-bin.000004

Read_Master_Log_Pos: 600 //#同步读取二进制日志的位置，大于等于Exec_Master_Log_Pos

Relay_Log_File: relay-bin.000003

Relay_Log_Pos: 251

Relay_Master_Log_File: mysql-bin.000004

Slave_IO_Running: Yes //此状态必须YES

Slave_SQL_Running: Yes //此状态必须YES

MySQL主从复制、搭建、状态检查、中断排查及备库重做 实战手册

美河学习在线https://www.wendangku.net/doc/1a3622148.html, MySQL主从复制 MySQL主从复制、搭建、状态检查、中断排查及备库重做 本文档主要对MySQL主从复制进行简单的介绍，包括原理简介、搭建步骤、状态检查、同步中断及排查、备库重建。

目录 一、MySQL主从复制概述 (2) 1、主从复制简介 (2) 2、主从复制原理、机制 (2) 3、主从复制原理图 (3) 二、MySQL主从复制搭建 (4) 1、Master端配置部署 (4) 2、Slave端配置部署 (4) 3、建立主从同步 (4) 三、主从复制状态检查及异常处理 (6) 1、主从复制状态检查 (6) 2、IO_thread异常 (7) 3、sql_thread异常 (8) 4、主从复制延迟 (9)

一、MySQL主从复制概述 1、主从复制简介 MySQL主从复制就是将一个MySQL实例（Master）中的数据实时复制到另一个MySQL实例(slave)中，而且这个复制是一个异步复制的过程。 实现整个复制操作主要由三个进程完成的，其中两个进程在Slave（sql_thread和IO_thread），另外一个进程在 Master（IO进程）上。 2、主从复制原理、机制 要实施复制，首先必须打开Master端的binary log（bin-log）功能，否则无法实现。因为整个复制过程实际上就是Slave从Master端获取该日志然后再在自己身上完全顺序的执行日志中所记录的各种操作。 复制的基本过程如下： 1)、Slave上面的IO_thread连接上Master，并请求从指定日志文件的指定位置（或者从最开始的日志）之后的日志内容； 2)、Master接收到来自Slave的IO_thread的请求后，通过负责复制的IO进程根据请求信息读取制定日志指定位置之后的日志信息，返回给Slave 的IO_thread。返回信息中除了日志所包含的信息之外，还包括本次返回的信息已经到Master端的bin-log file的以及bin-log pos； 3)、Slave的IO_thread接收到信息后，将接收到的日志内容依次添加到Slave端的relay-log文件的最末端，并将读取到的Master端的 bin-log的文件名和位置记录到master-info文件中，以便在下一次读取的时候能够清楚的告诉Master“我需要从某个bin-log的哪个位置开始往后的日志内容，请发给我”； 4)、Slave的Sql_thread检测到relay-log中新增加了内容后，会马上解析relay-log 的内容成为在Master端真实执行时候的那些可执行的内容，并在本数据库中执行。

数据架构规划

数据架构规划 一．当前架构 结合研发二部数据量最大的校讯通产品来描述，其他的产品在性能上出现瓶颈，可以向校讯通靠拢。 数据库整体架构：目前校讯通产品根据用户量的多少以及数据库服务资源的繁忙程度，横向采用了历史库+当前库的分库架构或者单一的当前库架构，其中历史库只作为web平台读数据库，纵向结合了applications的 memcache+Sybase ASE12.5传统永久磁盘化数据库架构。 数据模型架构：原则上采用了一事一地的数据模型（3NF范式），为了性能考虑，一些大数据量表适当的引用了数据冗余，根据业务再结合采用了当前表+历史表的数据模型。 以下就用图表来进行当前数据架构的说明： 横向分库数据库架构图：

纵向app layer+memcache layler+disk db layer图：

其中web层指的是客户端浏览器层，逻辑上：app层指的是应用服务层，mc 层指的是memcache的客户端层，ms层指的是memcache的服务层，db层指的是目前永久磁盘化的数据库层，当然在物理机器上可能app层跟mc层，ms层是重叠的部署在相同服务器上。 数据模型架构图：

其中以上数据模型中除了少数几张表外其他的都有历史表存在，当然有很多表是没在这个模型图中的，这部分是核心数据模型。这部分模型对象中也包括了一些冗余性的设计，比如用户中有真实姓名，特别是不在这个模型内，由模型核心表产生的一些统计报表，为了查询的性能冗余了合理一些学校名称，地区名称等方面的设计。 二．劣势现象 1.流水表性能瓶颈

当前架构的性能瓶颈集中在流水表的访问上，最大流水表的记录量达到了超5亿级别，这是由于目前外网在用的sybase数据库系统版本，没有采取很好的关于分区的技术。曾经有过把流水表进行物理水平分割，把不同月份的数据分割放在不同的物理表上的模型改造设想，碍于产生的应用程序修改工作量大，老旧数据迁移的麻烦，再加上进行了从单库架构改造到分库架构后，数据库性能瓶颈就不是特别突出。所以模型改造这部分工作没展开。 无论是单库或是分库的模式，出现平台访问数据库的性能瓶颈依然集中在大流水表上，在访问高峰高并发量情况下，短信的流水表进程堵塞，数据库服务 I/O ,CPU的资源耗费达到顶点，在服务器硬件环境不是特别理想情况下，出现了一定概率造成用户访问缓慢甚至觉得页面无法响应现象，造成了用户体念不良影响。 2. 运营维护难点 1)历史数据清理运维工作 为了存储充分利用，为了性能的提升，需要定期进行不再使用的历史数据清理， 由于清理的数据量庞大，传统的数据清理方法根本不可能保证一个晚上有效清理完毕，确保平台第二天正常的运行。虽然目前已经实行了比较高效且可行的数据清理方法，但是每次实行都需要晚上到通宵进行处理，使得数据清理的运维

数据库读写分离

随着一个网站的业务不断扩展，数据不断增加，数据库的压力也会越来越大，对数据库或者SQL的基本优化可能达不到最终的效果，我们可以采用读写分离的策略来改变现状。读写分离现在被大量应用于很多大型网站，这个技术也不足为奇了。ebay就做得非常好。ebay用的是oracle，听说是用Quest Share Plex 来实现主从复制数据。 读写分离简单的说是把对数据库读和写的操作分开对应不同的数据库服务器，这样能有效地减轻数据库压力，也能减轻io压力。主数据库提供写操作，从数据库提供读操作，其实在很多系统中，主要是读的操作。当主数据库进行写操作时，数据要同步到从的数据库，这样才能有效保证数据库完整性。Quest SharePlex就是比较牛的同步数据工具，听说比oracle本身的流复制还好，mysql也有自己的同步数据技术。mysql只要是通过二进制日志来复制数据。通过日志在从数据库重复主数据库的操作达到复制数据目的。这个复制比较好的就是通过异步方法，把数据同步到从数据库。 主数据库同步到从数据库后，从数据库一般由多台数据库组成这样才能达到减轻压力的目的。读的操作怎么样分配到从数据库上？应该根据服务器的压力把读的操作分配到服务器，而不是简单的随机分配。mysql提供了MySQL-Proxy实现读写分离操作。不过MySQL-Proxy 好像很久不更新了。oracle可以通过F5有效分配读从数据库的压力。

ebay的读写分离（网上找到就拿来用了） mysql的读写分离上面说的数据库同步复制，都是在从同一种数据库中，如果我要把oracle的数据同步到mysql中，其实要实现这种方案的理由很简单，mysql免费，oracle太贵。好像Quest SharePlex也实现不了改功能吧。好像现在市面还没有这个工具吧。那样应该怎么实现数据同步？其实我们可以考虑自己开发一套同步数据组件，通过消息，实现异步复制数据。其实这个实现起来要考虑很多

mysql主从

一、概述 MySQL从3.23.15版本以后提供数据库复制（replication）功能，利用该功能可以实现两个数据库同步、主从模式、互相备份模式的功能。本文档主要阐述了如何在linux系统中利用mysql的replication进行双机热备的配置。 二、环境 操作系统：Linux 2.6.23.1-42.fc8 # SMP（不安装XEN） Mysql版本：5.0.45-4.fc8 设备环境：PC（或者虚拟机）两台 三、配置 数据库同步复制功能的设置都在MySQL的配置文件中体现，MySQL的配置文件（一般是https://www.wendangku.net/doc/1a3622148.html,f）：在本环境下为/etc/https://www.wendangku.net/doc/1a3622148.html,f 。 3.1 设置环境： IP 的设置： A主机 IP：10.10.0.119 Mask：255.255.0.0 B主机 IP：10.10.8.112 Mask：255.255.0.0 在IP设置完成以后，需要确定两主机的防火墙确实已经关闭。可以使用命令service iptables status 查看防火墙状态。如果防火墙状态为仍在运行。使用service iptables stop 来停用防火墙。如果想启动关闭防火墙，可以使用setup 命令来禁用或定制。 最终以两台主机可以相互ping通为佳。 3.2 配置A主(master) B从(slave)模式 3.2.1 配置A 为master 1、增加一个用户同步使用的帐号： GRANT FILE ON *.* TO ‘backup’@'10.10.8.112' IDENTIFIED BY ‘1234’; GRANT REPLICATION SLAVE ON *.* TO ‘backup’@'10.10.8.112' IDENTIFIED BY ‘1234’; 赋予10.10.8.112也就是Slave 机器有File权限，只赋予Slave机器有File权限还不行，还要给它REPLICATION SLAVE的权限才可以。 2、增加一个数据库作为同步数据库： create database test; 3、创建一个表结构： create table mytest (username varchar(20),password varchar(20)); 4、修改配置文件： 修改A的/etc/https://www.wendangku.net/doc/1a3622148.html,f 文件，在https://www.wendangku.net/doc/1a3622148.html,f 配置项中加入下面配置：server-id = 1 #Server 标识 log-bin

MYSQL开发规范

MySQL DB规范

目录 简介 (3) 目的 (3) 适用范围 (3) 数据库设计 (3) 引擎及版本选择 (3) 基础规范 (3) 命名规范 (5) 库表设计规范 (5) 字段设计 (6) 常用数据类型： (6) 数据类型使用建议： (6) 索引规范 (8) 索引准则 (8) 索引禁忌 (8) 不使用外键 (9) SQL设计 (10)

简介 介绍在使用mysql中各种注意事项和优化细节 目的 供开发人员参考，合理利用MySQL特性，开发出更高效的代码减少后端数据库压力，让整个系统高效稳定运行适用范围 业务数据库使用的是MySQL的数据库。 数据库设计 实现目标：业务功能实现、数据的扩展性、普遍性适用性 业务中80%+的性能优化是来自架构设计的优化 引擎及版本选择 根据业务特性选择合适的存储引擎，默认选择InnoDB存储引擎，原因如下（MyISAM与InnoDB比较）： 基础规范 所有库表默认使用INNODB存储引擎,MyISAM适用场景非常少

●库表字符集使用UTF8，原因如下： 使用utf8字符集，如果是汉字，占3个字节，但ASCII码字符还是1个字节；统一不会有转换产生乱码风险；其他地区的用户（美国、印度、台湾）无需安装简体中文支持，就能正常看您的文字，并且不会出现乱码。 UTF-8最大的一个特点，就是它是一种变长的编码方式。它可以使用1~4个字节表示一个符号，根据不同的符号而变化字节长度。 UTF-8的编码规则很简单，只有二条： 1）对于单字节的符号，字节的第一位设为0，后面7位为这个符号的unicode码。因此对于英语字母，UTF-8编码和ASCII码是相同的。 2）对于n字节的符号（n>1），第一个字节的前n位都设为1，第n+1位设为0，后面字节的前两位一律设为10。剩下的没有提及的二进制位，全部为这个符号的unicode码。 ●所有表和字段都需要添加注释，以方便其它开发及dba了解 ●单表数据量纯int型建议控制在1000w以内，含char型的建议500w以内，行平均长度控制在16KB以内， 单表20GB以内 ●不在数据库中存储图片、文件等大数据.原因如下： 1、对数据库的读写速度永远赶不上文件系统的处理速度 2、数据库备份会变的很臃肿，备份很耗时间 3、对文件的访问需要通过你的应用和数据库 ●临时短命数据尽量不要存到数据库中，建议存放于前端的memcache、redis等nosql中,减少后端数据库压 力 ●禁止在线上做压力测试 ●禁止从测试、开发环境直接连接线上数据库 ●用数据库来持久化存储以及保证事务一致性，不是运算器，在应用层实现计算 ●读写分离，主库只写和少量实时读取请求，使用从库来查询。 ●采用队列方式合并多次写请求，持续写入避免瞬间压力 ●超长text/blob进行垂直拆分，并先行压缩 ●冷热数据进行水平拆分（如6个月前后数据），LRU原则 ●快速更新频繁和大数据表禁止直接运行count(*)统计 ●压力分散，在线表和归档表（日志表）分开存储；不重要的非实时查询日志不要存数据库，以文件方式 在应用端统计分析。 ●禁止明文存储机密数据，需至少两次加密（部分数据可逆运算）

数据库读写分离解决方案--DG实施方案

数据库读写分离解决方案 ----oracle 11G ADG实施方案

1.项目背景介绍 1.1目的 通过DG实现主库与备库同步,主库作为业务应用库,备库作为查询库,应用根据不同需求配置对应数据库; 1.2测试环境 在2台RedHat5.4上使用ORACLE 的DataGuard组件实现容灾。设备配置(VMWare虚拟机环境)清单如下：

2.Oracle DataGuard 介绍 备用数据库（standby database）是ORACLE 推出的一种高可用性(HIGH AVAILABLE)数据库方案，在主节点与备用节点间通过日志同步来保证数据的同步，备用节点作为主节点的备份，可以实现快速切换与灾难性恢复。 ●STANDBY DATABASE的类型： 有两种类型的STANDBY：物理STANDBY和逻辑STANDBY 两种类型的工作原理可通过如下图来说明： physical standby提供与主数据库完全一样的拷贝（块到块），数据库SCHEMA，包括索引都是一样的。它是可以直接应用REDO实现同步的。 l ogical standby则不是这样，在logical standby中，逻辑信息是相同的，但物理组织和数据结构可以不同，它和主库保持同步的方法是将接收的REDO转换成SQL语句，然后在STANDBY上执行SQL语句。逻辑STANDBY除灾难恢复外还有其它用途，比如用于用户进行查询和报表，但其数据库用户相关对象均需要有主键。 ?本次实施将选择物理STANDBY(physical standby)方式

●对主库的保护模式可以有以下三种模式： –Maximum protection (最高保护） –Maximum availability （最高可用性） –Maximum performance (最高性能） ?基于项目应用的特征及需求，本项目比较适合采用Maximum availability （最 高可用性）模式实施。

MySQL主从、主主复制及高可用性要点

一：MySQL复制： MySQL复制简介： 将master服务器中主数据库的ddl和dml操作通过二进制日志传到slaves服务器上，然后在master服务器上将这些日志文件重新执行，从而使得slave服务器和master服务器上的数据信息保持同步。 Mysql复制的原理： 将数据分布到多个系统上去，是通过将Mysql的某一台master主机的数据复制到其它（slave）主机上，并重新执行一遍来实现的； 复制过程中一个服务器充当master服务器，而一台或多台其它服务器充当slave服务器。master服务器将更新写入二进制日志文件，并维护文件的一个索引以跟踪日志循环。 这些日志可以记录发送到slave服务器的更新。当一个slaves服务器连接master服务器时，它通知master服务器从服务器在日志中读取的最后一次成功更新的位置。slave服务器接收从那时起发生的任何更新，然后封锁并等待master服务器通知新的更新。 mysql复制的优点： 在slave服务器上执行查询操作，降低master服务器的访问压力 当master服务器上出现了问题可以切换到slave服务器上，不会造成访问中断等问题 在slave服务器上进行备份，以避免备份期间影响master服务器的服务使用及日常访问

Mysql自身的复制功能：是构建大型、高性能应用程序的基础。 mysql支持的复制类型： 基于语句的复制：在主服务器上执行的SQL语句，在从服务器上执行同样的语句。MySQL默认采用基于语句的复制，效率比较高。一旦发现没法精确复制时，会自动选着基于行的复制。 基于行的复制：把改变的内容复制过去，而不是把命令在从服务器上执行一遍. 从mysql5.0开始支持 混合类型的复制:：默认采用基于语句的复制，一旦发现基于语句的无法精确的复制时，就会采用基于行的复制。 MySQL复制技术的特点： 数据分布(Data distribution ) 备份(Backups) 负载平衡(load balancing) 高可用性和容错性High availability and failover 复制的工作过程： master将改变记录到二进制日志(binary log)中（这些记录叫做二进制日志事件，binary log events）； slave将master的binary log events拷贝到它的中继日志(relay log)； slave重做中继日志中的事件，将改变反映它自己的数据。

网站MySQL数据库优化方案-主从架构及读写分离

网站MySQL数据库优化方案 网络运维信息管理中心 （2020年8月）

数据库为网站提供数据的结构化存储，是网站系统的重要组成部分，但随着业务逻辑的复杂度的增加，数据库需要不断的优化,单一的数据库已无法满足现在要求。 1.1优化目标 针对网站的MySQL数据库部署架构进行优化，其优化的目的是为了防止数据库出现单点故障问题，提高数据库的处理能力，提高数据库的可靠性，为保证网站业务正常办理。 1.2优化工作思路 1、对现有数据库现状分析包括现有数据库配置合理性分析、现有数据库部署情况两部分工作内容； 2、梳理现有网站的功能模块，目的是通过梳理网站的各功能模块对数据读取时效性，分析其是否可以实现读写； 3、以数据库主从架构及数据库读写分离方式，对网站的MySQL 数据库提出数据库部署架构优化的方案，数据库主从架构的多数据库模式，解决数据库单点存在的问题，当主数据库出现宕机时，可以将从数据库代替主数据库恢复业务系统正常运行，而且避免数据的丢失，提高数据库高可靠性和高可用性；通过部分查询统计功能，实现数据库读写分离，以便对数据库负载进行分流，缓解主数据库的读取压力。

2.1当前数据库部署架构图 当前网站的数据库采用单台MySQL数据库提供数据库服务，当前部署架构图如下： 2.2现有数据库主要配置梳理

2.3数据库部署情况梳理 2.3.1数据库安装部署情况梳理 2.3.2现有应用连接数据库情况梳理 连接数据库的应用系统有会员管理、权限管理、订单模块、商品管理、促销管理、广告管理、报表统计、文章管理、评论管理、系统设置、数据库管理、短信管理、推荐管理、邮件群发管理等。2.3.3数据库服务启动、停止方式梳理 1、启动命令 （1）普通启动：/data/soa/mysql/bin/mysqld （2）centos6以前版本：service start mysqld （3）centos7+：systemctl mysqld start

Mycat MySQLGalera读写分离验证安装手册

Mycat+MySQL Galera读写分离验证作者菜菜-李梦嘉56335443 部署MySQL Galera 安装环境 安装前准备 安装gcc、gcc-c++ # yum install gcc gcc-c++ 安装boost-devel # yum install boost-devel 安装scons check-devel openssl-devel # yum install scons check-devel openssl-devel 安装libaio # yum install libaio 安装perl、perl-devel # yum install perl perl-devel 安装rsync、lsof # yum install rsync lsof MySQL Galera安装 安装含wsrep Patch的MySQL # tar zxvf mysql-wsrep-5.6.27-25.12-linux-x86_64.tar.gz # mv mysql-wsrep-5.6.27-25.12-linux-x86_64 /usr/local/mysql

# groupadd mysql # useradd -r -g mysql mysql # chown -R mysql:mysql . # ./scripts/mysql_install_db --no-defaults --datadir=/usr/local/mysql/data --user=mysql # chown -R root . # chown -R mysql data # ln -s /usr/local/mysql/bin/* /usr/sbin 安装Galera复制插件 # tar zxvf galera-3-25.3.13.tar.gz # cd galera-3-25.3.13 # scons # cp garb/garbd /usr/local/mysql/bin/ # cp libgalera_smm.so /usr/local/mysql/lib/plugin/ 配置MySQL Galera # cp /usr/local/mysql/support-files/mysql.server /etc/init.d/mysqld # mkdir -p /var/lib/mysql # chown mysql:mysql /var/lib/mysql # vi /etc/https://www.wendangku.net/doc/1a3622148.html,f [client] port = 3306 socket = /var/lib/mysql/mysql.sock [mysqld_safe] log-error = /var/lib/mysql/mysql.log pid-file = /var/lib/mysql/mysql.pid [mysqld] wsrep_node_name = node1 wsrep_provider = /usr/local/mysql/lib/plugin/libgalera_smm.so #wsrep_provider_options ='gcache.size=1G;socket.ssl_key=my_key;socket.ssl_cert=my_cert' #wsrep_slave_threads=16 wsrep_sst_method = rsync

数据库使用情况分析

数据库使用情况分析 一、警报日志： 1）计算一个月插入数据 目前操作为15S会执行一次数据库操作；假设有2000台；那么；一个月的数据为： 单枪柜： 4*60*24*30＝240 0000 如果为2000台： 240*2000＝40000W 这是极限值； 2）计算数据库插入频率 按时间权限处理算下数据库插入操作频率： 15S/2000 =7ms执行一次插入操作 3）数据查询 数据库的数据要与其他的表用ID做关联，那么这个操作会更糟糕；因为警报日志表中在7ms就会执行一个插入动作，所以关联的查询如果在7ms中检索不出来，检索的数据就会有脏数据；（检索和插入动作产生冲突，数据库在处理检索和插入的同时还会处理他们的冲突事情） 由上可以看出数据库的性能要远远高于7ms才可以 以上为单张表警报日志处理极限值分析； 以上解决方法： 1）插入执行时间加长到1个小时，相当于执行极限频率提高到7ms*60*4=5s 2）分库，把此单张表移到一个单独数据库中； 3）换中型数据库MSSQL 或大型数据库ORACLE； 二、取枪还枪日志极限值分析 1）枪弹柜取枪与还枪动插入操作 枪弹柜取枪与还枪动作限定每天执行一支枪一个动作；每个枪弹柜只有十支枪，子弹不用取还计算； 一个枪弹柜一天执行的动作数： 1*10＝10次；

按2000枪弹柜计算： 一个月执行的次数为： 10*2000*30＝30 0000数据； 取还枪表一个月的数据要有30W数据存在；一年大约为400W数据分为两张表，单张表一年数据也近200W； 2）取还枪执行频率 最坏计算： 所有取枪人员在上班同一时间（一小时）取枪计算执行频率为 1*60*60/20000＝0.06S 按上述频率计算，数据库的性能至少是执行每个动作不超过0.06s 就不会产生冲突；（数据不会丢或不会出错），但一般数据库中表关联查询（多表查询）都差不止要这个时间；所以产生冲突的可能必会很大；数据库一定要可以处理这种冲突； 三、整个数据库计算 如果计算最坏情况下数据库的使用频率 应该是： 一个60ms执行一次一个7ms执行一次；最坏计算是420ms产生一次冲突（取还枪与警报日志）；也就是一秒内会有至少产生两次冲突的可能； 而单独警报日志自身不同动作（插入、删除）是0.007S产生一次冲突，数据库会可能会产生一次冲突； 四、解决方案 1）优化数据库和程序代码； 缺点：对程序员和数据库优化人员的技术要求高； 优点：数据库可以继续使用目前数据库 2）数据分库、数据库读写分离； 缺点：程序需要修改 优点：动作很容易实现 3）换大型数据库（MSSQL 或ORACLE）； 缺点：可能需要收费（如果我们项目可以使用破解版本，就可以不用担心）， 优点：直接把结构COPY即可；对程序员和数据库优化人员要求低； 4）如果换库建议使用破解版本ORACLE或MSSQL；

上海Linux运维工程师-面习题-练习-个人总结)

这下面的是一个企业发的面试题 1你常上的相关技术站有哪些？ 2简述你所理解运维工程师的主要职责？ 3你管理过的服务器数量级？ 1台 2台 2-5台 5-10台 10台以上 4描述一次你印象深刻的服务器运维经历。 5有一台服务器出现安全问题，你会采取什么样的方法处理？说出你的诊断处理思路。 6有多台服务器需部署相同应用文件，文件会持续更新，你用什么方式实现不同服务器间的文件同步。 7某一台服务器部署多个Web站点，其中有一个w3wp的CPU占用达到100%，如何找出有问题的Web站点？ 8你眼中的沪江是怎样的？谈谈你对沪江的理解。 9是否有以下相关经验？如有请简要说明掌握情况。 a、Squid相关经验 b、Nginx、Lighttpd等 c、Memcached d、负载均衡 e、分布式文件处理 f、Email Server 上午-10点雷傲普文化传播有限公司 1.DNS使用的端口号和协议，简单描述一下DNS正向解析和反向解析的工作原理和作用还 有应用场景？ 2．编写IPTABLES使用内网某台机器的80端口可以在公网访问，假设公网IP为10.10.1.1 ，实现192.168.1.0/32段的NAT. 3.举出三个以上的主流WEB服务器，并简述他们的特性和优缺点不限操作系统？ Apache 源代码开放可以欲行在unix，windowns，linux平台上，可移植性，而且模块很是丰富缺点：性能，速度上不及其他轻量级的web服务器，但是也是重量级产品，所消耗的内存，cpu也比其他的要高 Nginx 源代码开放发高性能的http和反向代理服务器，在高并发的情况下，nginx 是apache不错的替代品，他能够支持高达50000个并发连接响应，内存，cpu等系统资源消耗也是很低的。缺点，支持模块比较少吧，相对没有apache稳定，支持动态页面

mysql读写分离

Linux下Mysql源码安装笔记 安装步骤: 1.解压mysql-5.1.55.tar.gz 命令: tar -zxvf mysql-5.1.55.tar.gz 2.配置Mysql 命令:./configure --prefix=/usr/local/mysql 说明:安装到/usr/local/mysql下,当然用别的也行,还有其它参数可以查看相关文档. 3.编译,安装 命令: make make install 这两个命令发的时间较长. 4.创建用户和组. groupadd mysql useradd -g mysql mysql 5.进入mysql目录.创建var目录.并把./share/Mysql/https://www.wendangku.net/doc/1a3622148.html,f 拷到Mysql目录下并改名为https://www.wendangku.net/doc/1a3622148.html,f. >mkdir var >mv share/mysql/https://www.wendangku.net/doc/1a3622148.html,f https://www.wendangku.net/doc/1a3622148.html,f 6.配置https://www.wendangku.net/doc/1a3622148.html,f 配置主要把安装的目录的那几项打开就行. 7.安装数据库 命令:./bin/Mysql_install_db 说明:必须用参数--defaults-file指定https://www.wendangku.net/doc/1a3622148.html,f,否则系统用默认的/etc/https://www.wendangku.net/doc/1a3622148.html,f.

8.安装完后,可以看到mysql/var目录下有数据文件,然后用下面命令设置权限: shell> chown -R root . shell> chown -R mysql var shell> chgrp -R mysql . 9.启动数据库. ./bin/Mysqld_safe 10.进入数据库. ./bin/mysql -u root – 默认时没有密码,当然如果你删除/etc/https://www.wendangku.net/doc/1a3622148.html,f,可以不要后面的--defaults-file=/test/Mysql/https://www.wendangku.net/doc/1a3622148.html,f ./bin/Mysql -u root --socket=/tmp/Mysql3306 也就行了,原因大家应该知道吧!^_^! 11.设为服务并自启动. 对于设置为服务只要把mysql/share/mysql/mysql.server放到/etc/init.d/下改名为mysql 命令: mv share/mysql/mysql.server /etc/init.d/mysql chmod 775 /etc/init.d/mysql chkconfig --add mysql 总结,这只是安装了一个3306端口的mysql,如果要在装一个msyql,步骤一样,只要改动https://www.wendangku.net/doc/1a3622148.html,f文件的内容. 设置用户权限： grant all privileges on *.* to 'root'@'%' identified by 'ZJLT&https://www.wendangku.net/doc/1a3622148.html,' with grant opt ion; 备： server-id = 2 master-host=192.168.1.14 replicate-do-db=appmarket master-user=root master-password=ZJLT&https://www.wendangku.net/doc/1a3622148.html,

mysql主从数据库服务器的设置

mysql 主从数据库服务器的设置 MySQL主从服务器（Replication）的设置： 1.首先在主服务器上为从服务器建立一个账户 mysql>grant replication slave on *.* to '用户名'@'主机' identified by '密码'; 2.登录从服务器使用步骤一申请的用户名和密码访问主数据库如果可以访问代表建立用户成功 mysql -u 用户名 -p密码 -h 主数据库IP -P3306 如果不能正常访问可能是防火墙的原因，可以停掉防火墙看看情况 /etc/iptables stop 3.编辑主数据库服务器配置文件 vi /etc/ #slave-config-start------------------ server-id=3（主从服务器server-id不能重复） binlog-do-db=需要复制的数据库名称 binlog-ignore-db=不需要复制的数据库名称 binlog-ignore-db=不需要复制的数据库名称

lower_case_table_names=1（大小写相同） #slave-config-end-------------------- 4.编辑从数据库服务器配置文件 vi /etc/ #slave-config-start---------------------------- server-id=2 master-host=主数据库服务器IP master-user=步骤一分配的用户名 master-password=步骤一分配的密码 master-port=3306 replicate-do-db=cetv master-connect-retry=60 lower_case_table_names=1 #slave-config-end------------------------------5.手动备份导入使主从数据库的数据一致 Slave_IO_Running: No Slave_SQL_Running: Yes 的解决方法 1.首先到主数据库中

数据库规范

数据库相关规范 1.使用utf8mb4字符集 2.所有表、字段必须写清中文注释 3.金额字段禁止使用小数存储（单位：分） 4.禁止使用字段属性隐式转换（如：“WHERE ms_no = 1234”ms_no为字符串类型） 5.尽量不使用负向查询（NOT、!=、<>、!<、!>、NOT IN、NOT LIKE等） 6.禁止使用外键，如有完整性约束，需要应用程序控制 7.禁止使用程序配置文件内的账号访问线上数据库 8.禁止非DBA对线上数据库进行写操作 9.开发、测试、线上环境分离 10.所以提交的SQL语句必须经过测试 11.禁止存储大文件或大照片 12.库名、表名、字段名：小写，下划线分割，不超过32个字符，必须见名知意，禁止拼 音英文混用 13.表必须有主键 14.必须把字段定义为NOT NULL并设置默认值 15.必须使用varchar（20）来存储手机号 16.单表索引控制在5个以内，单索引字段数不许超过5个 a)索引的使用。? b)(1) 尽量避免对索引列进行计算。如计算较多，请提请管理员建立函数索引。? c)(2) 尽量注意比较值与索引列数据类型的一致性。? d)(3) 对于复合索引，SQL语句必须使用主索引列? e)(4) 索引中，尽量避免使用NULL。? f)(5) 对于索引的比较，尽量避免使用NOT=（!=）? g)(6) 查询列和排序列与索引列次序保持一致 (7) 禁止在更新频繁、区分度不高（如：性别）的字段上建立索引 (8) 建立组合索引，必须把区分度高的字段放在前面 17.禁止使用SELECT * ，只获取必要的字段 18.禁止使用INSERT INTO t_xxx VALUES(xxx)，必须指定插入的列名 19.禁止在WHERE条件的属性上使用函数或表达式 20.禁止%开头的模糊查询 21.禁止使用OR条件 22.应用程序必须捕获SQL异常，并作出相应处理 23.逻辑删除代替物理删除 24.选择最有效的表名、查询条件顺序（从右到左） 25.减少访问数据库的次数 26.SQL中的关键字均使用大写字母，数据表最好起别名 27.查询条件中“>=”代替“>” 28.等号两边使用空格，逗号后使用空格 29.多表操作必须使用别名 30.整条语句必须写明注释，关键逻辑单独书写注释，说明算法、功能 a)注释风格：注释单独成行、放在语句前面。? b)(1) 应对不易理解的分支条件表达式加注释；? c)(2) 对重要的计算应说明其功能；?

Mysql数据库安装及生产环境下主从库同步配置

Mysql数据库安装及生产环境下主从库同步配置

目录 1安装M YSQL数据库...................................................................................................................................... 2生产环境下M Y SQL数据库主从同步配置................................................................................................. 2.1 主数据库配置 (5) 2.2 从数据库配置 (5) 3监控服务器............................................................................................................................................... 3.1 监控主数据库服务器 (6) 3.2 监控从数据库服务器 (6)

1安装Mysql数据库 安装环境： 系统：CentOS-6.6-x86_64 数据库：MySQL-server-5.5.42-1.el6.x86_64；MySQL-client-5.5.42-1.el6.x86_64 1.SSH方式登录到MySQL服务器 2.创建存放安装文件的目录 [root@localhost /]# mkdir -p /sw/mysql55 3.上传安装文件到上一步创建的目录 4.检查是否已安装过MySQL [root@localhost /]# rpm -qa | grep -i mysql MySQL-client-5.5.42-1.el6.x86_64 MySQL-server-5.5.42-1.el6.x86_64 5.如果已安装则移除，否则请跳过此步 [root@localhost /]# yum -y remove MySQL-server-5.5.42-1.el6.x86_64 [root@localhost /]# yum -y remove MySQL-client-5.5.42-1.el6.x86_64 删除老版本mysql的开发头文件和库 rm -fr /usr/lib/mysql rm -fr /usr/include/mysql rm -fr /var/lib/mysql rm -f /etc/https://www.wendangku.net/doc/1a3622148.html,f 6.安装MySQL [root@localhost /]# cd /sw/mysql55/ [root@localhost mysql55]# rpm -ivh MySQL-server-5.5.42-1.el6.x86_64.rpm Preparing... ########################################### [100%] 1:MySQL-client ########################################### [100%] [root@localhost mysql55]# rpm -ivh MySQL-client-5.5.42-1.el6.x86_64.rpm Preparing... ########################################### [100%] 1:MySQL-server ########################################### [100%] 7.配置MySQL [root@localhost mysql55]# cp /usr/share/mysql/https://www.wendangku.net/doc/1a3622148.html,f /etc/https://www.wendangku.net/doc/1a3622148.html,f [root@localhost mysql55]# vi /etc/https://www.wendangku.net/doc/1a3622148.html,f [client] #password = your_password port = 8819 socket = /var/lib/mysql/mysql.sock default-character-set=utf8 [mysqld] port = 8819 socket = /var/lib/mysql/mysql.sock lower_case_table_names=1

数据共享集群和读写分离集群的服务名配置

数据共享集群和读写分离集群的服务名配置 DMDSC Dameng Data Shared Clusters，达梦数据共享集群。 DMRWC Dameng Read/Write Clusters，达梦读写分离集群。 1. DMDSC在生产环境中用的越来越多，就有应用配置连接字符串的问题，首先需配置dm_svc.conf（类似于Oracle的tnsnames.ora），如下： time_zone=(480) language=(en) dmrac=(192.168.0.1:5236,192.168.0.2:5236) switch_time=(10000) switch_interval=(1000) loadBalance=(true) loadBalanceFreq=(10000) loadBalancePercent=(10) dmrac: 服务名，配置DSC节点的IP和端口。 loadBalance : 是否负载均衡 loadBalanceFreq: 负载均衡的频率 然后需要配置的URL字符串: url="jdbc:dm://dmrac:5236?comOra=true&loadBalance=true&loadBalanceF req=10000" comOra: 是否兼容ORACLE模式 & ：转义字符，转义为& 2. 读写分离集群（DMRWC）服务名配置： TIME_ZONE=(480) LANGUAGE=(en) DM_RWW=(192.168.0.151:5236,192.168.0.152:5236,192.168.0.153:5236) RW_SEPARATE=(1) RW_PERCENT=(30) LOGIN_PRIMARY=(1) SWITCH_TIME=6000

MYSQL主从数据库介绍__主库__从库

如上图所示，整个数据层有Group1，Group2，Group3三个集群组成，这三个集群就是数据水平切分的结果，当然这三个集群也就组成了一个包含完整数据的DB。每一个Group包括1个Master（当然Master也可以是多个）和N个Slave，这些Master和Slave的数据是一致的。比如Group1中的一个slave发生了宕机现象，那么还有两个slave是可以用的，这样的模型总是不会造成某部分数据不能访问的问题，除非整个Group里的机器全部宕掉，但是考虑到这样的事情发生的概率非常小（除非是断电了，否则不易发生吧）。 在没有引入集群以前，我们的一次查询的过程大致如下：请求数据层，并传递必要的分库区分字段（通常情况下是user_id）?数据层根据区分字段Route到具体的DB?在这个确定的DB内进行数据操作。这是没有引入集群的情况，当时引入集群会是什么样子的呢？看图一即可得知，我们的路由器上规则和策略其实只能路由到具体的Group，也就是只能路由到一个虚拟的Group，这个Group并不是某个特定的物理服务器。接下来需要做的工作就是找到具体的物理的DB服务器，以进行具体的数据操作。基于这个环节的需求，我们引入了负载均衡器的概念（LB）。负载均衡器的职责就是定位到一台具体的DB服务器。具体的规则如下：负载均衡器会分析当前sql的读写特性，如果是写操作或者是要求实时性很强的操作的话，直接将查询负载分到Master，如果是读操作则通过负载均衡策略分配一个Slave。我们的负载均衡器的主要研究放向也就是负载分发策略，通常情况下负载均衡包括随机负载均衡和加权负载均衡。随机负载均衡很好理解，就是从N个Slave中随机选取一个Slave。这样的随机负载均衡是不考虑机器性能的，它默认为每台机器的性能是一样的。假如真实的情况是这样的，这样做也是无可厚非的。假如实际情况并非如此呢？每个Slave的机器物理性能和配置不一样的情况，再使用随机的不考虑性能的负载均衡，是非常不科学的，这样一来会给机器性能差的机器带来不必要的高负载，甚至带来宕机的危险，同时高性能的数据库服务器也不能充分发挥其物理性能。基于此考虑从，我们引入了加权负载均衡，也就是在我们的系统内部通过一定的接口，可以给每台DB服务器分配一个权值，然后再运行时LB根据权值在集群中的比重，分配一定比例的负载给该DB服务器。当然这样的概念的引入，无疑增大了系统的复杂性和可维护性。有得必有失，我们也没有办法逃过的。 有了分库，有了集群，有了负载均衡器，是不是就万事大吉了呢？事情远没有我们想象的那么简单。虽然有了这些东西，基本上能保证我们的数据层可以承受很大的压力，但是这样的设计并不能完全规避数据库宕机的危害。假如Group1中的slave2 宕机了，那么系统的LB并不能得知，这样的话其实是很危险的，因为LB不知道，它还会以为slave2为可用状态，所以还是会给slave2分配负载。这样一来，问题就出来了，客户端很自然的就会发生数据操作失败的错误或者异常。这样是非常不友好的！怎样解决这样的问