整合营销服务商

电脑端+手机端+微信端=数据同步管理

免费咨询热线:

技术分享 - MySQL 内部临时表是怎么存放的

技术分享 - MySQL 内部临时表是怎么存放的

者:胡呈清


爱可生 DBA 团队成员,擅长故障分析、性能优化,个人博客:https://www.jianshu.com/u/a95ec11f67a8,欢迎讨论。


本文来源:原创投稿


*爱可生开源社区出品,原创内容未经授权不得随意使用,转载请联系小编并注明来源。


如果 SQL 在执行过程中读到的数据无法直接得到结果,那么就需要额外的内存来保存中间结果,得出最终结果,这个额外的内存就是内部临时表。比如 group by 执行时,就需要构建一个临时表,需要额外的字段保存聚合函数的结果,当然为了防止内存使用过大,一般超出某个限制后就会放到磁盘上。关于哪些操作会产生内部临时表,可以查看官方文档:https://dev.mysql.com/doc/refman/8.0/en/internal-temporary-tables.html,下面主要介绍 MySQL8.0 内部临时表存放方式的变化。

MySQL 5.6

MySQL 5.6 中,内部临时表大小超过内存限制后是在临时目录中的单个表文件表空间中创建的,如果禁用了 innodb_file_per_table ,则在数据目录中的 InnoDB 共享表空间(ibdata1)中创建,很容易造成 ibdata1 过大,并且无法释放,只能逻辑导出数据迁移到新实例解决。

MySQL 5.7

MySQL 5.7 在临时表空间上做了改进,已经实现将临时表空间从 InnoDB 共享表空间或者独立表空间中分离,现在叫共享临时表空间。好处有二:

  1. 可以消除为每个临时表创建和删除的性能成本;
  2. 是一块单独为内部临时表划分的表空间,重启 mysqld 可以重置其大小,避免 MySQL5.6 时 ibdata1 难以释放的问题。

其表现是 MySQL 启动时 datadir 下会创建一个 ibtmp1 文件,默认值下会无限扩展。例如,如果某个 SQL 执行时创建了一个大小为 20MB 的内部磁盘临时表,则创建时默认大小为 12MB 的临时表空间文件会扩展到 20MB 以适应该表。当 SQL 执行完删除临时表时,释放的空间可以重新用于新的临时表,但 ibtmp1 文件保持扩展大小,只有重启 MySQL 时才会真正回收共享临时表空间变成初始大小 12MB。

相关参数:

  • tmp_table_size&max_heap_table_size,内部临时表是存在内存中的,使用 MEMORY 存储引擎,如果大小超过了这两者较小的值,则会转化为磁盘临时表;
  • internal_tmp_disk_storage_engine:如果内部临时表转化为磁盘临时表,则这个参数指定了磁盘临时表的存储引擎,默认是 INNODB,还可以设置为 MYISAM;
  • innodb_temp_data_file_path:指定了临时表空间的位置和大小,默认值为 ibtmp1:12M:autoextend ,即 datadir/ibtmp1,初始大小12M可以无限扩展,建议限制一个最大值防止把磁盘撑满。

缺点:SQL 执行完产生的内部临时表可能很大,必须要重启才能释放。这点曾一度让我很困惑,为什么不能做的更好一点执行完就释放呢?所幸 MySQL8.0 优化了这个问题。

MySQL 8.0

MySQL 8.0又有较大变化,新增了一些参数:

  • internal_tmp_mem_storage_engine:用来指定在内存中的内部临时表的存储引擎,默认值 TempTable,而非以前默认的 MEMORY
  • temptable_max_ram:定义 TempTable 存储引擎开始在磁盘上存储数据之前可以占用的最大内存量,默认值1G
  • temptable_use_mmap:定义当 TempTable 存储引擎占用的内存量超过 temptable_max_ram 变量定义的限制时,TempTable 存储引擎是否为内存中的内部临时表分配空间作为内存映射的临时文件。 禁用 temptable_use_mmap 时,将使用 InnoDB 磁盘内部临时表代替。默认值ON,8.0.16引入,8.0.26弃用。
  • temptable_max_mmap:定义 TempTable 存储引擎在开始将数据存储到磁盘上的 InnoDB 内部临时表之前,被允许从内存映射的临时文件分配的最大内存量(以字节为单位)。设置为0将禁用从内存映射的临时文件分配内存。默认值1G,8.0.23引入。

内存映射临时文件

也就是说,默认情况下执行 SQL 产生内部临时表,使用的存储引擎从 MEMORY 变成了 TempTable,当然 TempTable 依然是一种内存表,可以使用的最大内存是1G(默认)。当大小超过1G,会使用内存映射临时文件作为内部临时表的溢出机制,大白话就是防止内存使用太大,把内存中的数据放在临时文件中。

但是你想想,关系型数据库设计了存储引擎这么好的东西来存放数据,这时候用文件来存是不是过分了点?估计官方是这么想的:哎呀内部临时表很小的,我就临时放放,你忍忍。后来发现有些内部临时表太大了忍不了,为了防止内存映射临时文件过大,8.0.23版本引入一个新参数 temptable_max_mmap 来限制其大小,如果超过其大小(默认1G),则转化为磁盘临时表(这点和 MySQL 5.7一致)。值得注意的是 temptable_use_mmap 参数 8.0.26 标记被弃用了,官方文档也提示建议设置为0将其关闭,所以个人理解使用内存映射临时文件作为内部临时表的溢出机制是一个糟糕的方案。

TempTable

为什么要把内部临时表默认引擎换成 TempTable ?它与 MEMORY 最大的不同是:

  • 可以支持变长类型,例如 varchar(100)的数据”abcd”应该只占用4个字节而非100个字节,节省内存;
  • 支持二进制大对象,例如 blob, text 等。如果使用 MEMORY 引擎,这样的内部临时表会直接使用磁盘临时表,这个是为了提升性能。

那么真的那么好用吗?目前最新版本是8.0.26,还是存在一些问题的,例如: https://bugs.mysql.com/bug.php?id=98782 https://bugs.mysql.com/bug.php?id=98739 https://bugs.mysql.com/bug.php?id=99593 https://bugs.mysql.com/bug.php?id=99100

前3个都是性能问题,后面一个则可能会导致 SQL 执行时报错:The table '/tmp/#sql639b7_13_4' is full,所以在这些问题解决前,建议设置internal_tmp_mem_storage_engine=MEMORY

临时表空间

MySQL 8.0 临时表空间也发生了变化,分为了会话临时表空间全局临时表空间内,全局临时表空间内和 MySQL 5.7 时没什么两样,不过 SQL 产生的内部临时表将存储在会话临时表空间中。

新参数:

  • innodb_temp_tablespaces_dir :定义了创建会话临时表空间的位置,默认位置是数据目录中 #innodb_temp的目录
shell> ls datadir/#innodb_temp
temp_10.ibt  temp_2.ibt  temp_4.ibt  temp_6.ibt  temp_8.ibt
temp_1.ibt   temp_3.ibt  temp_5.ibt  temp_7.ibt  temp_9.ibt

会话临时表空间其实是个包含10个临时表空间的池,会话临时表空间在第一次请求创建磁盘临时表时从临时表空间池中分配给会话。一个会话最多分配两个表空间,一个用于用户创建的临时表,另一个用于优化器创建的内部临时表。当会话断开连接时,其临时表空间被清除并释放回池中。

测试现象

temptable_use_mmap=ON 时,如果内部临时表超过了 temptable_max_ram 大小,使用内存映射的临时文件用作内部临时表的溢出机制,临时文件放在 tmpdir 目录下:

可以看到临时文件数量+1,磁盘临时表数量不变:

temptable_use_mmap=OFF 时,如果内部临时表超过了temptable_max_ram 大小,使用 InnoDB 磁盘内部临时表用作内部临时表的溢出机制,存放在 innodb 会话临时表空间中,与 MySQL 5.7 的区别是,session 断开后就会释放空间,不需要重启 MySQL :

可以看到临时文件数量不变,磁盘临时表数量+1:

者:小不点啊

来源:www.cnblogs.com/leeSmall/p/9356535.html

一、Nginx Rewrite 规则


1. Nginx rewrite规则


Rewrite规则含义就是某个URL重写成特定的URL(类似于Redirect),从某种意义上说为了美观或者对搜索引擎友好,提高收录量及排名等。


语法:


rewrite <regex> <replacement> [flag]
关键字 || 正则 || 替代内容 || flag标记


Rewrite规则的flag标记主要有以下几种:


  • last :相当于Apache里的(L)标记,表示完成rewrite;
  • break:本条规则匹配完成后,终止匹配,不再匹配后面的规则
  • redirect:返回302临时重定向,浏览器地址会显示跳转后的URL地址
  • permanent:返回301永久重定向,浏览器地址栏会显示跳转后的URL地址


last和break用来实现URL重写,浏览器地址栏URL地址不变


2. Nginx rewrite例子


a) 例如用户访问www.dbspread.com,想直接跳转到网站下面的某个页面,www.dbspread.com/new.index.html如何来实现呢?我们可以使用Nginx Rewrite 来实现这个需求,具体如下:在server中加入如下语句即可:


效果图如下:

                rewrite     ^/$    http://www.dbspread.com/new.index.html  permanent;
对应如下语法:
                rewrite    <regex>    <replacement>                 [flag];
                关键字      正则        替代内容                    flag标记

正则表达式说明:

*代表前面0或更多个字符                +代表前面1或更多个字符
?代表前面0或1个字符                  ^代表字符串的开始位置
$代表字符串结束的位置                 。为通配符,代表任何字符

b)例如多个域名跳转到同一个域名,nginx rewrite规则写法如下:


格式:

rewrite <regex> <replacement> [flag];
关键字 || 正则 || 替代内容 || flag标记


说明:


  • rewrite为固定关键字,表示开始进行rewrite匹配规则、
  • regex部分是 ^/(.*) ,这是一个正则表达式,匹配完整的域名和后面的路径地址
  • replacement部分是http://www.dbspread.com/,是取自regex部分( )里的内容。匹配成功后跳转到的URL。
  • flag部分 permanent表示永久301重定向标记,即跳转到新的 http://www.dbspread.com/ 地址上



二、Nginx 防盗链


1. 什么是防盗链


比如http://www.dbspread.com/download/av123.rmvb 这个视频下载地址被其他网站引用,比如在www.test.com的index.html引用download/av123.rmvb就叫盗链,我们要禁止这种引用就叫做防盗链



2. 怎么实现防盗链


在nginx的nginx.conf的server里面配置如下代码


三、Nginx 动静分离

1. 动静分离是什么

Nginx动静分离是让动态网站里的动态网页根据一定规则把不变的资源和经常变的资源区分开来,动静资源做好了拆分以后,我们就可以根据静态资源的特点将其做缓存操作,这就是网站静态化处理的核心思路。

2. 动静分离原理图

3. Nginx动静分离应该注意的地方

1). WEB项目开发时要注意,将静态资源尽量放在一个static文件夹2). 将static静态资源文件夹放到Nginx可以取到的位置3). 页面要建立全局变量路径,方便修改路径4). 修改nginx.conf的location, 匹配静态资源请求

4. Nginx动静分离步骤

4.1 准备一个静态资源button.css

body {
    margin: 10px 20px;
    text-align: center;
    font-family: Arial, sans-serif;
    background-color: red;
}

4.2 在/var/local下新建一个static文件夹用来存放静态资源button.css

4.3 在tomcat-8080/webapps/ROOT下的index.html里面引入button.css


4.4 在nginx的nginx.conf中server节点新增静态资源分离的配置


对于Nginx基础配置,推荐之前的:后端实践:Nginx日志配置(超详细)

4.5 访问页面查看效果

四、Nginx+keepalived 实现高可用

1. keepalived是什么

Keepalived软件起初是专为LVS负载均衡软件设计的,用来管理并监控LVS集群系统中各个服务节点的状态,后来又加入了可以实现高可用的VRRP (Virtual Router Redundancy Protocol ,虚拟路由器冗余协议)功能。因此,Keepalived除了能够管理LVS软件外,还可以作为其他服务(例如:Nginx、Haproxy、MySQL等)的高可用解决方案软件

2. keepalived主要功能

管理LVS负载均衡软件实现LVS集群节点的健康检查作为系统网络服务的高可用性(failover)

3. keepalived故障转移

Keepalived高可用服务之间的故障切换转移,是通过 VRRP 来实现的。在 Keepalived服务正常工作时,主 Master节点会不断地向备节点发送(多播的方式)心跳消息,用以告诉备Backup节点自己还活着,当主 Master节点发生故障时,就无法发送心跳消息,备节点也就因此无法继续检测到来自主 Master节点的心跳了,于是调用自身的接管程序,接管主Master节点的 IP资源及服务。而当主 Master节点恢复时,备Backup节点又会释放主节点故障时自身接管的IP资源及服务,恢复到原来的备用角色。

说明:keepalived的主从切换和redis的主从切换是不一样的,keepalived的主节点挂了以后,从节点变为主节点,之前的主节点恢复以后继续做主节点。redis的主节点挂了以后,重新恢复以后变为从节点

4. keepalived高可用架构示意图

说明:

虚拟ip(VIP):192.168.152.200,对外提供服务的ip,也可称作浮动ip192.168.152.130:nginx + keepalived master 主192.168.152.129:nginx + keepalived backup 从192.168.152.129:tomcat-8080192.168.152.129:tomcat-8081

5. keepalived安装

环境准备:

centos6、jdk

虚拟ip(VIP):192.168.152.200,对外提供服务的ip,也可称作浮动ip
192.168.152.130:nginx + keepalived master 主
192.168.152.129:nginx + keepalived backup 从
192.168.152.129:tomcat-8080
192.168.152.129:tomcat-8081

nginx和tomcat的环境准备请查看我的前一篇关于nginx的文章

5.1 安装keepalived的步骤:

注:192.168.152.129(keepalived从节点) 与 192.168.152.130(keepalived主节点)先安装好nginx + keepalived

下载压缩包:

wget www.keepalived.org/software/keepalived-1.3.5.tar.gz

解压缩:

tar -zxvf keepalived-1.3.5.tar.gz

进入解压缩以后的文件目录:

cd keepalived-1.3.5

编译安装:./configure --prefix=/usr/local/keepalived系统提示警告 *** WARNING - this build will not support IPVS with IPv6. Please install libnl/libnl-3 dev libraries to support IPv6 with IPVS.yum -y install libnl libnl-devel再次执行./configure --prefix=/usr/local/keepalived系统提示错误 configure: error: libnfnetlink headers missingyum install -y libnfnetlink-devel再次执行./configure --prefix=/usr/local/keepalived

make && make install

到此keepalived安装完成,但是接下来还有最关键的一步,如果这一步没有做后面启动keepalived的时候会报找不到配置文件的错误

Configuration file '/etc/keepalived/keepalived.conf' is not a regular non-executable file

安装完成后,进入安装目录的etc目录下,将keepalived相应的配置文件拷贝到系统相应的目录当中。keepalived启动时会从/etc/keepalived目录下查找keepalived.conf配置文件

mkdir /etc/keepalived

cp /usr/local/keepalived/etc/keepalived/keepalived.conf /etc/keepalived

5.2 修改keepalived主节点192.168.152.130的/etc/keepalived/keepalived.conf配置文件


5.3 修改keepalived从节点192.168.152.129的/etc/keepalived/keepalived.conf配置文件

5.4 检查nginx是否启动的shell脚本


/usr/local/src/check_nginx_pid.sh

#!/bin/bash
#检测nginx是否启动了
A=`ps -C nginx --no-header |wc -l`        
if [ $A -eq 0 ];then    #如果nginx没有启动就启动nginx                        
      /usr/local/nginx/sbin/nginx                #重启nginx
      if [ `ps -C nginx --no-header |wc -l` -eq 0 ];then    #nginx重启失败,则停掉keepalived服务,进行VIP转移
              killall keepalived                    
      fi
fi


5.5 192.168.152.130(keepalived主节点)和 192.168.152.129(keepalived从节点)的nginx的配置文件nginx.conf

user root root; #使用什么用户启动NGINX 在运行时使用哪个用户哪个组
worker_processes 4; #启动进程数,一般是1或8个,根据你的电脑CPU数,一般8个
worker_cpu_affinity 00000001 00000010 00000100 00001000; #CPU逻辑数——把每个进程分别绑在CPU上面,为每个进程分配一个CPU
#pid /usr/local/nginx/logs/nginx.pid
worker_rlimit_nofile 102400; #一个进程打开的最大文件数目,与NGINX并发连接有关系

#工作模式及连接数上限
events
{
  use epoll; #多路复用IO 基于LINUX2.6以上内核,可以大大提高NGINX的性能 uname -a查看内核版本号
  worker_connections 102400; #单个worker process最大连接数,其中NGINX最大连接数=连接数*进程数,一般1GB内存的机器上可以打开的最大数大约是10万左右
  multi_accept on;   #尽可能多的接受请求,默认是关闭状态
}

#处理http请求的一个应用配置段
http
{
  #引用mime.types,这个类型定义了很多,当web服务器收到静态的资源文件请求时,依据请求文件的后缀名在服务器的MIME配置文件中找到对应的MIME #Type,根据MIMETYPE设置并response响应类型(Content-type)
  include       mime.types; 
  default_type  application/octet-stream; #定义的数据流,有的时候默认类型可以指定为text,这跟我们的网页发布还是资源下载是有关系的
  fastcgi_intercept_errors on; #表示接收fastcgi输出的http 1.0 response code
  charset utf-8;
  server_names_hash_bucket_size 128; #保存服务器名字的hash表
  #用来缓存请求头信息的,容量4K,如果header头信息请求超过了,nginx会直接返回400错误,先根据client_header_buffer_size配置的值分配一个buffer,如果##分配的buffer无法容纳request_line/request_header,那么就会##再次根据large_client_header_buffers配置的参数分配large_buffer,如果large_buffer还是无#法容纳,那么就会返回414(处理request_line)/400(处理request_header)错误。
  client_header_buffer_size 4k; 
  large_client_header_buffers 4 32k;
  client_max_body_size 300m; #允许客户端请求的最大单文件字节数 上传文件时根据需求设置这个参数
  #指定NGINX是否调用这个函数来输出文件,对于普通的文件我们必须设置为ON,如果NGINX专门做为一个下载端的话可以关掉,好处是降低磁盘与网络的IO处理数及#系统的UPTIME
  sendfile on; 
  #autoindex on;开启目录列表访问,适合下载服务器
  tcp_nopush on; #防止网络阻塞
  #非常重要,根据实际情况设置值,超时时间,客户端到服务端的连接持续有效时间,60秒内可避免重新建立连接,时间也不能设太长,太长的话,若请求数10000##,都占用连接会把服务托死
  keepalive_timeout 60;
  tcp_nodelay on; #提高数据的实时响应性
  client_body_buffer_size 512k; #缓冲区代理缓冲用户端请求的最大字节数(请求多)

  proxy_connect_timeout   5; #nginx跟后端服务器连接超时时间(代理连接超时)
  proxy_read_timeout      60; #连接成功后,后端服务器响应时间(代理接收超时)
  proxy_send_timeout      5; #后端服务器数据回传时间(代理发送超时)
  proxy_buffer_size       16k; #设置代理服务器(nginx)保存用户头信息的缓冲区大小
  proxy_buffers           4 64k; #proxy_buffers缓冲区,网页平均在32k以下的话,这样设置
  proxy_busy_buffers_size 128k; #高负荷下缓冲大小
  proxy_temp_file_write_size 128k; #设定缓存文件夹大小,大于这个值,将从upstream服务器传

  gzip on; #NGINX可以压缩静态资源,比如我的静态资源有10M,压缩后只有2M,那么浏览器下载的就少了
  gzip_min_length  1k;
  gzip_buffers     4 16k;
  gzip_http_version 1.1;
  gzip_comp_level 2; #压缩级别大小,最小1,最大9.值越小,压缩后比例越小,CPU处理更快,为1时,原10M压缩完后8M,但设为9时,压缩完可能只有2M了。一般设置为2
  gzip_types       text/plain application/x-javascript text/css application/xml; #压缩类型:text,js css xml 都会被压缩
  gzip_vary on; #作用是在http响应中增加一行目的是改变反向代理服务器的缓存策略

#日志格式 
log_format  main '$remote_addr - $remote_user [$time_local] "$request" ' #ip 远程用户 当地时间  请求URL
                 '$status $body_bytes_sent "$http_referer" ' #状态  发送的大小  响应的头
         '"$http_user_agent" $request_time'; #客户端使用的浏览器  页面响应的时间

#动态转发         
upstream web1 {
    #每个请求按访问ip的hash结果分配,这样每个访客固定访问一个后端服务器,可以解决session的问题。配置了ip_hash就没有负载均衡的效果了,每次访问的都是同一个tomcat
    #ip_hash; 
    #转发的后端的tomcat服务器,weight表示转发的权重,越大转发的次数越多,机器性能不一样配置的weight值不一样     
     server   192.168.152.129:8080 weight=1 max_fails=2 fail_timeout=30s;
     server   192.168.152.129:8081 weight=1 max_fails=2 fail_timeout=30s;
}
upstream web2 {
     server   192.168.152.129:8090 weight=1 max_fails=2 fail_timeout=30s;
     server   192.168.152.129:8091 weight=1 max_fails=2 fail_timeout=30s;
}

server {
    listen       80; #监听80端口
    server_name  www.dbspread.com; #域名
    #rewrite规则
    index  index.jsp index.html index.htm;
    root   /usr/local/nginx/html; #定义服务器的默认网站根目录位置
    #重定向
    if ($host != 'www.dbspread.com' ){ 
            rewrite ^/(.*)$  http://www.dbspread.com/$1  permanent;
            }

    #防盗链
     location ~* \.(rmvb|jpg|png|swf|flv)$ { #rmvb|jpg|png|swf|flv表示对rmvb|jpg|png|swf|flv后缀的文件实行防盗链
                valid_referers none blocked  www.dbspread.com; #表示对www.dbspread.com此域名开通白名单,比如在www.test.com的index.html引用download/av123.rmvb,无效
                root   html/b;
                if ($invalid_referer) { #如果请求不是从www.dbspread.com白名单发出来的请求,直接重定向到403.html这个页面或者返回403 
                     #rewrite ^/ http://www.dbspread.com/403.html;
                     return 403;
                }
        }

    #监听完成以后通过斜杆(/)拦截请求转发到后端的tomcat服务器
    location / 
        {
            #如果后端的服务器返回502、504、执行超时等错误,自动将请求转发到upstream负载均衡池中的另一台服务器,实现故障转移。
            proxy_next_upstream http_502 http_504 error timeout invalid_header;
            proxy_set_header Host  $host; #获取客户端的主机名存到变量Host里面,从而让tomcat取到客户端机器的信息
            proxy_set_header X-Real-IP $remote_addr; #获取客户端的主机名存到变量X-Real-IP里面,从而让tomcat取到客户端机器的信息
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            #rewrite     ^/$    http://www.dbspread.com/new.index.html  permanent;#用户访问www.dbspread.com,想直接跳转到网站下面的某个页面:www.dbspread.com/new.index.html
            proxy_pass http://web1; #跳转到对应的应用web1
        }

       # location ~ .*\.(php|jsp|cgi|shtml)?$ #动态分离 ~匹配 以.*结尾(以PHP JSP结尾走这段)
       #  {
       #     proxy_set_header Host  $host;
       #        proxy_set_header X-Real-IP $remote_addr;
       #        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
       #        proxy_pass http://jvm_web2;
       # }

        #静态分离 ~匹配 以.*结尾(以html|htm|gif|jpg|jpeg|bmp|png|ico|txt|js|css结尾走这段),当然不是越久越好,如果有10000个用户在线,都保存几个月,系统托跨
        location ~ .*\.(html|htm|gif|jpg|jpeg|bmp|png|ico|txt|js|css)$ 
        {
            root /var/local/static; #静态资源存放在nginx的安装机器上
            #proxy_pass http://www.static.com; #静态资源也可存放在远程服务器上
            expires    30d;
        }

        #日志级别有[debug|info|notice|warn|error|crit]  error_log 级别分为 debug, info, notice, warn, error, crit  默认为crit, 生产环境用error 
        #crit 记录的日志最少,而debug记录的日志最多
        access_log  /usr/local/logs/web2/access.log main;
        error_log   /usr/local/logs/web2/error.log  crit;

    }


}


到这一步环境准备已完成,相关的配置也修改完成,下面我们来查看效果


5.6 配置hosts域名映射


192.168.152.200  www.dbspread.com

注意:这里192.168.152.200 是keepalived里面virtual_ipaddress配置的虚拟ip

 virtual_ipaddress {
        192.168.152.200 # 定义虚拟ip(VIP),可多设,每行一个
    }


到这一步环境准备已完成,相关的配置也修改完成,下面我们来查看效果


5.7 分别启动192.168.152.129的两个tomcat


5.8 分别启动192.168.152.130(keepalived主节点)和

192.168.152.129(keepalived从节点)的keepalived的

启动命令:


/usr/local/keepalived/sbin/keepalived  

可以看到keepalived和nginx都启动了

在浏览器输入www.dpspread.com域名访问

5.9 下面我们停掉主节点192.168.152.130的keepalived和nginx

可以看到从节点变为主节点了

在浏览器输入地址www.dpspread.com访问,可以看到访问正常

5.10 下面我们重新启动主节点192.168.152.130

可以看到主节点重新启动以后变为主节点了

之前变为主节点的从节点又变回从节点了

到此keepalived+nginx的高可用完美完成

CSDN 编者按】MySQL之父Monty有着四十多年的编程经验,从儿时的兴趣到长大后的深耕,他在编程领域不断钻研,最终成为编程大师。《新程序员004》带你走进Monty的程序人生,谈谈他在编程方面的最新感悟以及对未来的预测。

作者 | 郭露 责编 | 徐威龙

出品 | 《新程序员》编辑部

如今,我们正处于数据爆炸的时代,软件崛起的背后是数据的支持。而随着开源技术的发展,越来越多的数据库选择创建开源社区,让更多的开发者参与到数据库的建设中来。

在开源数据库领域中,Michael "Monty" Widenius(通常称为Monty)绝对是不得不提的代表人物。有着四十多年编程经验的Monty是MySQL和MariaDB的作者,也是开源软件运动的著名倡导者,即便是现在他也在坚持写代码。作为影响了几代技术人的数据库,MySQL所取得的成就无需多言。而最初作为MySQL分支立项的MariaDB也在迅速成长,同样在数据库中赢得了一席之地。

Monty近照(图源自Wiki)

作为在技术届游历半生的资深“程序员”,Monty对编程的理解也有许多独到之处,他认为只有学习编程20年以上,才能像读懂音乐一样,看出编程之美。除此之外,他还表示:“写代码时要尽量将代码一次性写成,而不是写完后再没完没了地修改。”只有做到这一点,才能称得上是一名优秀的程序员。而这也是他长久以来所遵循的“编程法则”。

近期,《新程序员》有机会邀请Monty分享他的程序人生,谈谈他对于技术的感悟,以及对于数据库发展的看法与心得。

1.“我在编程方面有一定的天赋”

1962年,Monty出生在芬兰首都赫尔辛基,小时候的他便对计算机有着浓厚的兴趣。1978年,年仅16岁的Monty用他一整个暑假打工攒的钱买了人生中的第一台电脑,并且用BASIC语言写下了第一行代码REM,从此以后他便与编程结下了不解之缘。三年后,Monty被北欧著名高校赫尔辛基理工大学录取,但由于自己的学习理念与学校不同,他感到在学校学不到什么东西,因此没过多久就辍学了。1981年。离开了校园的Monty开始在荷兰的一家叫做Tapio Laakso Oy的公司当程序员。在近十年之后,34岁的Monty开发出了历史上最流行的开源数据库之一——MySQL。

Monty能开发出MySQL并非偶然,他在编程上投入了大量的时间。根据早期的资料显示,就连别人去参加聚会时,他也在家里写代码。在他看来,好的代码不需要一次又一次地重写,而是在开始写之前,就抱有一次写成的心态。正因为如此,直到多年后的今天,Monty仍然直言“自己在编程方面具有一定的天赋”。

除了Monty,MySQL的诞生还离不开David Axmark和Allan Larsson。早在1980年,17岁的Monty打算将自己的计算机内存从8KB提高到16KB。机缘巧合之下,他去往瑞典Allan Larsson的电脑店寻求帮助,在那里认识了同样也是写代码的David Axmark,之后三人就成为了亲密的合作伙伴,经常一起写代码,解决编程过程中遇到的问题。1995年,三人创立了MySQL AB,MySQL AB就是MySQL的雏形。这其中Monty负责了大部分的开发工作。最终,在1996年10月,MySQL首个版本发布,从此掀开了数据库历史的重要一章。

到了1999年,MySQL的迅速发展已经引起了许多人的注意, Oracle表示要以5000万美元的价格收购MySQL。然而Monty三人并不想止步于此,也不想失去对MySQL的控制,因此拒绝了这次收购。

随着时间的推移,MySQL迅速发展, 但同时市场上也出现了包括PostgreSQL在内的竞争对手数据库。为了在竞争中脱颖而出,MySQL开始接受融资,以获得更大的发展机会。到了2003年,MySQL实现了高达400万的安装次数,较两年前翻了一番,成为了当时全世界最受欢迎的开源数据库。

2008年1月16日,Sun Microsystems以高达10亿美元的价格收购MySQL(然而次年Sun又被Oracle收购)。当时Monty担心MySQL可能会受到Oracle的控制而变得商业化,并且如果Oracle一家独大的话,可能会引发数据库领域的不良竞争。于是他发起了一场拯救MySQL的请愿活动,并在MySQL闭源前将其分化,以其小女儿Maria的名字命名创建了MariaDB。

设计MariaDB的初衷(图源自MariaDB官网)

MariaDB开源数据库可以看做是MySQL的一个分支,主要由开源社区维护,目的是要完全兼容MySQL,甚至包括API和命令行。MariDB推出后,不少MySQL的员工都转而投向MariaDB,甚至是原先使用MySQL的各大公司也将数据库迁移到MariaDB上,其中就包括谷歌和维基百科。Monty表示:“与MySQL相比,MariaDB更加成熟,拥有更大的研发优势,并且在安全性修复方面也更加出色。”直到现在,Monty依旧亲自参与MariaDB的开发维护,可以说他的工作重心都在MariaDB上。

Monty的小女儿Maria(图源自MariaDB官网)

2.MariaDB,坚持开源的背后

邹欣:你在创建MariaDB时,曾提到要把它打造成第二个MySQL,并且确保它是开源的。那么对于数据库而言,为什么开源这么重要呢?

Monty:对于任何大型项目来说,开源都是非常重要的。既然要和巨头竞争,你就要有和他们一样的工具。在我看来,开源很适合用于软件开发,尤其是当公司规模还不大的时候。这个时候你很难兼顾公司和用户的需求,因此需要听取别人的想法。而开源就意味着可以获得社区的帮助,能够了解其他人的观点。有了开源,你可以开发出更好的产品,同时产品也能够获得更大的影响力。

邹欣:不过开源的一大弊端就是声音太多,需求不一,这种情况下该如何保证数据库能满足大多数人的需求呢?

Monty:要解决这个问题,就需要确保数据库足够灵活,这样才能满足大多数人的需求。在这一点上,MySQL和MariaDB的做法是建立各种性能不一的存储引擎,人们可以针对具体需求开发自己的存储引擎 。

事实上,对于那些有需求的人来说,MariaDB依旧是一个优秀的工具。而对于要求数据库体量较小且运行较快的人来说,MariaDB同样是一个不错的选择。在开发MariaDB时,我们考虑到了各种可能性,使它能够保持良好的性能。

邹欣:AI技术的发展让人们对数据库的期待发生了转变,今天数据库是否能够与AI技术结合,从而拥有数据决策能力?

Monty:对于数据库来说,最重要的是要处理AI需要的不同结构。因此我们添加了对JSON的支持,用于在MariaDB中支持动态列。这样人们就可以储存并检索数据,同时保留自己想要的格式。通常AI并不是要创造内容,更多的是实现文件自动化,这就是我们对于MariaDB所抱的期望。因此这两者完全是不同的工具集。

除此之外,我们还需要一个良好的环境,其中每一个部分都是可替代的,要确保自己不被束缚。一旦有了束缚的存在,那么你的应用程序就需要与静态系统相结合,这会大大降低灵活性。我认为对于数据库来说,要注意的一点就是,要确保数据库容易上手,而这恰恰意味着更多的AI技术能够整合到数据库中。

3.仍然每天坚持写代码

邹欣:在中国IT行业有这样一种现象,认为程序员过了35岁就要转型,进入管理层或是其他领域。对此你怎么看?

Monty:这在很多地方都很常见。这个现象的主要原因在于程序员在管理岗位上的工资要比单纯做编程高。因为很少有公司会重视优秀的程序员,这就导致了收入的差异。我认为,如今程序员没有晋升的空间。与其让他们被迫转型,不如建立一个能提升他们收入的新环境。要想做到这一点,公司就得让他们承担更多的责任。要程序员担任管理岗位也行,但前提是仍然要保证他们每天写代码的时间。毕竟好的经理人到处都是,好的程序员却千里挑一。

邹欣:据我所知,你仍然每天在坚持写代码,但同时也要负责MariaDB的运营和管理。那么,你如何平衡这两个身份呢?

Monty:我认为在写代码这方面,我还是有一点天分的,所以我想坚持下去。我会雇用经理人为我工作,这样我就可以做我最擅长的事情。我会参与代码审查、社区运营以及MariaDB的相关决策。但同时我也会花很多时间维系客户,与不同国家的开发者交流,其中有许多中国的开发者。我认为,除了写代码之外,这是我做的最重要的事。总而言之,我会雇佣经理人来做一部分管理,让我有足够的时间在真正重要的事情上。

邹欣:听闻你从20世纪80年代就开始在家办公,如今这一办公方式也开始流行起来,对于远程办公你有什么看法?

Monty:事实上我认为远程办公是非常灵活的工作方式,自1981年开始我就在家办公(MySQL和MariaDB团队都是在家办公)。我们招人之前可能从来没见过他们,甚至都不知道对面是个人还是团队。但是我们的效率一直都在线。能做到这一点的前提,是要对跟自己联系密切的同事有足够的了解。至少熟悉他们的样貌。

我认为对于八成的开发者而言,在家办公是一个不错的选择。可能有一小部分开发者,他们的工作负担比较重,在家提不起精神来。这就需要他们出去走走,见见朋友或是接触新事物。我刚开始在家办公的时候,也会担心这样是不是会被孤立。所以后来我会定期在家里举行派对,我也会亲自下厨。我们团队每年也会在一起待上一段时间。

4.一个好的程序员能抵五个一般的程序员

邹欣:对于你来说,在过去几年数据库领域发生了哪些大的变化?

Monty:在过去的五年或七年间,学习SQL(结构化查询语言)开始成为一种趋势。但是人们发现SQL过于复杂,因此还需要学习其他语言。于是许多公司开始创新,采用NoSQL(非关系型数据库) 进行开发。但在过去的几年里,人们逐渐意识到NoSQL并不是万金油。但选择关系型数据库是否能够涵盖NoSQL提供的功能?很明显,有的可以 ,有的不行。因此我认为,在当下的环境中,对于数据库的要求在于要保证云端以及本地部署。

我们不能被一个数据库束缚。云端提供的是灵活性,你能在数据库中运行软件,即使是有成百上千个软件,而且本地部署的价格更低,控制权限更高,这一点是云端无法提供的。但我依然认为云端有它的优势,我们要在两者之间找到平衡。

邹欣:30年前我从大学毕业时,人们提到数据库一般是指去银行办业务。现在看来,人们有了更多的选择,我们能够借助数据库实现许多功能。但提到数据库开发时,人们往往指的是“后端”。那么,对于一个开发者或是毕业生想要进入数据库领域的人来说,你会给他们怎样的职业建议?

Monty:在我看来,从开源数据库开始入门更简单。现在开源数据库很多,如果你的确想成为专家级别的人,想要得到一份很好的工作,你可以找一个合适的数据库,并学习如何进行优化。但同时你也需要了解人们的需求,你可以和从事这一行的同学交流,并且学习解决数据库中的实际问题。

邹欣:除了多参与开源项目之外,对于中国开发者你还有哪些想说的?

Monty:我和来自中国的开发者有过非常多的互动,他们非常棒,在编程上表现得非常优秀。不过我在感到惊喜的同时,也感到非常惋惜,因为他们都想转型做管理。我认为这是最大的错误。他们需要让老板给自己派更多的任务,当然也可以做管理,但前提是能让自己写代码。还是那句话:找到一个好经理很容易,但找到一个好的程序员很难。一个非常出色的程序员可以抵五个一般的程序员,关键是你想当一个好的程序员还是一个平庸的经理。对于所有中国开发者,我只想说,请坚持你的工作,你已经做得非常好了,一定不要停止写代码

【参考资料】

https://zh.wikipedia.org/wiki/%E7%B1%B3%E5%8D%A1%E5%9F%83%E7%88%BE%C2%B7%E7%B6%AD%E5%BE%B7%E7%B4%90%E6%96%AF

https://blog.openocean.vc/founder-stories-a-hackers-hacker-6d5054c90564

https://huskyintelligence.com/leverage-open-source-code/

http://monty-says.blogspot.com/2009/12/help-saving-mysql.html

https://www.geeksforgeeks.org/introduction-of-mariadb/

http://www.josetteorama.com/from-mysql-to-mariadb-michael-%e2%80%9cmonty%e2%80%9d-widenius-talks-about-databases-and-his-projects/

https://dri.es/the-history-of-mysql-ab

https://mariadb.org/wp-content/uploads/2019/11/MySQL-MariaDB-story.pdf