MySQL 5.6通过Keepalived+互为主从实现高可用架构

本文涉及的产品
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
传统型负载均衡 CLB,每月750个小时 15LCU
云数据库 RDS MySQL,高可用系列 2核4GB
简介:

本文将介绍两台Mysql如何实现高可用架构。通常我们会配置主从同步,但这样若主的Mysql挂掉,还需要手动干预,例如把指向主库的IP地址修改为指向从库的IP,为了实现自动切换到从数据库,我们可以使用Keepalived配置一个浮动的VIP出来供前端访问,主的Mysql故障了VIP会立即自动切换到从的Mysql,省去了人工干预的时间,但要想故障的那台Mysql起来后也能作为从Mysql自动去同步数据,就需要配置成互为主从。拥有VIP的Mysql可认为是主库,才能进行数据的写入,由于VIP可以在两台Mysql之间浮动切换,因此这两台mysql是互为主从。

一、测试环境

操作系统版本:Red Hat Enterprise Linux Server release 6.5 (Santiago)

Mysql版本:MySQL-5.6.38-1.el6.x86_64.rpm-bundle.tar

keepalived版本:keepalived-1.2.7-3.el6.x86_64.rpm

node01:192.168.10.71

node02:192.168.10.72

VIP:192.168.10.70


二、配置node01为主、node02为从的主从同步

1、node01和node02分别安装好Mysql 5.6.38,安装方法请参考上一篇博文MySQL 5.6.38在RedHat 6.5上通过RPM包安装


2、在node01和node02分别编辑/etc/my.cnf,配置如下:

[mysqld]

log-bin=mysql-bin

server-id = 1


[mysqld_safe]

log-error = /var/log/mysqld.log

pid-file = /var/run/mysqld/mysqld.pid

replicate-do-db = all


3、重启mysql服务

[root@node01 ~]# service mysql restart

[root@node02 ~]# service mysql restart


4、登录node01的mysql,创建用于同步的账户repl,密码为123456,并查询master状态,记下file名称和posttion数值

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

Query OK, 0 rows affected (0.00 sec)

mysql> show master status;

861ce21efcab668e198c869c519b558c.png


5、登录node02的mysql,执行以下语句开启从服务器,注意master_host要填写node01的IP

mysql> change master to master_host='192.168.10.71',master_user='repl',master_password='123456',master_log_file='mysql-bin.000001',master_log_pos=318;

Query OK, 0 rows affected, 2 warnings (0.36 sec)

1
2
3
4
5
6
7
命令参数解释:
master_host='192.168.10.71' ## Master 的 IP 地址
master_user='repl' ## 用于同步数据的用户(在 Master中授权的用户)
master_password='123456' ## 同步数据用户的密码
master_log_file='mysql-bin.000001' ##指定 Slave 从哪个日志文
件开始读复制数据(可在 Master 上使用 show master status 查看到日志文件名)
master_log_pos=429  ## 从哪个 POSITION 号开始读


mysql> start slave;

Query OK, 0 rows affected (0.03 sec)


6、查询从服务的状态,状态正常

5d73613426a065162d40691ea633ae3c.png

7、在node01创建一个数据库、一个表并插入一行数据,用于测试node02是否能同步过去

mysql> create database mysql_long;

Query OK, 1 row affected (0.00 sec)


mysql> use mysql_long;

Database changed


mysql> create table test(id int(3),name char(5));

Query OK, 0 rows affected (0.13 sec)


mysql> insert into test values (001,'jlong');

Query OK, 1 row affected (0.01 sec)

96706addc3684365ab116e4367f26d4f.png


8、登录到node02的Mysql,同步正常

0648ce6f610307f25c3735364ec1b9d6.png


三、配置node02为主、node01为从的主从同步

1、登录node02的mysql,创建用于同步的账户repl,密码为123456,并查询master状态,记下file名称和posttion数值,并查询master状态

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

Query OK, 0 rows affected (0.00 sec)

Query OK, 0 rows affected (0.10 sec)


2ccd74beec248c31114882b518d34d95.png


2、登录node01的mysql,执行以下语句开启从服务器,注意这里master_host要填写node02的IP

mysql> change master to master_host='192.168.10.72',master_user='repl',master_password='123456',master_log_file='mysql-bin.000001',master_log_pos=318;

Query OK, 0 rows affected, 2 warnings (0.36 sec)


mysql> start slave;

Query OK, 0 rows affected (0.03 sec)


3、查询从服务的状态,状态正常

e00bd2e54a3046d63fa7ac76b0889f55.png


4、在node02创建一个数据库、一个表并插入一行数据,用于测试node01是否能同步过去

mysql> create database mysql_long2;

Query OK, 1 row affected (0.00 sec)


mysql> use mysql_long2;

Database changed


mysql> create table test2(id int(3),name char(10));

Query OK, 0 rows affected (0.71 sec)


mysql> insert into test2 values (001,'jianlong');


Query OK, 1 row affected (0.00 sec

64ea39fae7345681a7e2ce1f414fe90e.png


5、node01同步正常。

6190935c9e4ae273051f021a7ce91f68.png


这样互为主从就配置好了,两台机既是对方的Master,又是对方的Slave,无论在哪一台机上数据发生了变化,另一台都能及时进行同步数据,下面我们开始配置keepalived实现高可用。


四、keepalived配置

1、在node01上使用yum安装keepalived

[root@node01 ~]# yum install keepalived -y

d473381c95e2b41b33cf177cc31d843e.png


2、在node02上也使用yum安装keepalived

[root@node02 ~]# yum install keepalived -y

1984e99300267658ac24f7f2c107fbf4.png


3、编辑node01的keepalived的配置文件

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
[root@node01 ~] # cat /etc/keepalived/keepalived.conf  
! Configuration File  for  keepalived
  
global_defs {
    notification_email {
      acassen@firewall.loc
      failover@firewall.loc
      sysadmin@firewall.loc
    }
    notification_email_from
       Alexandre.Cassen@firewall.loc
    smtp_server 192.168.200.1
    smtp_connect_timeout 30
    router_id LVS_DEVEL
}
  
vrrp_instance VI_1 {
     state BACKUP    ##node01和node02都配置成BACKUP,角色由优先级确定
     interface eth2
     virtual_router_id 71
     priority 100       ##node01的优先级设置比node02的高
     advert_int 1
     nopreempt         ##设置不抢占(需在BACKUP状态下设置才有效)
     authentication {
         auth_type PASS
         auth_pass 1111
     }
     virtual_ipaddress {
         192.168.10.70
     }
}
  
virtual_server
192.168.10.70 3306 {
     delay_loop 6
     lb_algo wrr
     lb_kind DR
     nat_mask 255.255.255.0
     persistence_timeout 50
     protocol TCP
  
     real_server 192.168.10.71 3306 {
         weight 100
         notify_down  /etc/keepalived/stopkeepalived .sh  #3306端口不可用则执行脚本
         TCP_CHECK {
         connect_timeout 10
         nb_get_retry 3
         delay_before_retry 3
         connect_port 3306           
  
         }
     }
}


4、编辑node02的keepalived的配置文件

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
[root@node02 ~] # cat /etc/keepalived/keepalived.conf  
! Configuration File  for  keepalived
  
global_defs {
    notification_email {
      acassen@firewall.loc
      failover@firewall.loc
      sysadmin@firewall.loc
    }
    notification_email_from
       Alexandre.Cassen@firewall.loc
    smtp_server 192.168.200.1
    smtp_connect_timeout 30
    router_id LVS_DEVEL
}
  
vrrp_instance VI_1 {
     state BACKUP        ##node01和node02都配置成BACKUP,角色由优先级确定
     interface eth3
     virtual_router_id 71
     priority 90         ##node02的优先级设置比node01的低
     advert_int 1
     nopreempt           ##设置不抢占(需在BACKUP状态下设置才有效)
     authentication {
         auth_type PASS
         auth_pass 1111
     }
     virtual_ipaddress {
         192.168.10.70
     }
}
  
virtual_server
192.168.10.70 3306 {
     delay_loop 6
     lb_algo wrr
     lb_kind DR
     nat_mask 255.255.255.0
     persistence_timeout 50
     protocol TCP
  
     real_server 192.168.10.72 3306 {
         weight 100
         notify_down  /etc/keepalived/stopkeepalived .sh  #3306端口不可用则执行脚本
         TCP_CHECK {
         connect_timeout 10
         nb_get_retry 3
         delay_before_retry 3
         connect_port 3306           
  
         }
     }
}
  
[root@node02 ~] #

5、node01和node02都编辑一个keepalived的自杀脚本/etc/keepalived/stopalived.sh,一旦检测到Mysql的3306端口不通,便执行此脚本触发vip的切换,脚本内容很简单,就是service keepalived stop就行,因为keepalived服务停止便会触发高可用的切换动作。


6、启动keepalived服务

[root@node01 ~]# service keepalived start

Starting keepalived:                                       [  OK  ]

[root@node02 ~]# service keepalived start

Starting keepalived:                                       [  OK  ]


7、观察node01的message日志,由于node01的优先级高,因此进入了master角色,vip也已经加上了

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
[root@node01~] # tail -f /var/log/messages
Oct 30 22:47:46
node01 Keepalived[3170]: Starting Keepalived v1.2.7 (09 /26 ,2012)
Oct 30 22:47:46
node01 Keepalived[3171]: Starting Healthcheck child process, pid=3173
Oct 30 22:47:46
node01 Keepalived[3171]: Starting VRRP child process, pid=3174
Oct 30 22:47:46
node01 Keepalived_vrrp[3174]: Interface queue is empty
Oct 30 22:47:46
node01 Keepalived_vrrp[3174]: Netlink reflector reports IP 192.168.10.71 added
Oct 30 22:47:46 
node01 Keepalived_vrrp[3174]: Netlink reflector reports IP
fe80::20c:29ff:fe20:a6c8 added
Oct 30 22:47:46
node01 Keepalived_vrrp[3174]: Registering Kernel netlink reflector
Oct 30 22:47:46
node01 Keepalived_vrrp[3174]: Registering Kernel netlink  command  channel
Oct 30 22:47:46
node01 Keepalived_vrrp[3174]: Registering gratuitous ARP shared channel
Oct 30 22:47:46
node01 kernel: IPVS: Registered protocols (TCP, UDP, SCTP, AH, ESP)
Oct 30 22:47:46
node01 kernel: IPVS: Connection  hash  table configured (size=4096,memory=64Kbytes)
Oct 30 22:47:46
node01 kernel: IPVS: ipvs loaded.
Oct 30 22:47:46
node01 Keepalived_vrrp[3174]: Opening  file  '/etc/keepalived/keepalived.conf' .
Oct 30 22:47:46
node01 Keepalived_vrrp[3174]: Configuration is using : 63319 Bytes
Oct 30 22:47:46
node01 Keepalived_vrrp[3174]: Using LinkWatch kernel netlink reflector...
Oct 30 22:47:46
node01 Keepalived_healthcheckers[3173]: Interface queue is empty
Oct 30 22:47:46
node01 Keepalived_healthcheckers[3173]: Netlink reflector reports IP
192.168.10.71 added
Oct 30 22:47:46
node01 Keepalived_healthcheckers[3173]: Netlink reflector reports IP
fe80::20c:29ff:fe20:a6c8 added
Oct 30 22:47:46
node01 Keepalived_healthcheckers[3173]: Registering Kernel netlink reflector
Oct 30 22:47:46
node01 Keepalived_healthcheckers[3173]: Registering Kernel netlink  command  channel
Oct 30 22:47:46
node01 Keepalived_healthcheckers[3173]: Opening  file  '/etc/keepalived/keepalived.conf'
Oct 30 22:47:46
node01 Keepalived_healthcheckers[3173]: Configuration is using : 11970 Bytes
Oct 30 22:47:46
node01 Keepalived_vrrp[3174]: VRRP sockpool: [ifindex(2), proto(112), fd(11,12)]
Oct 30 22:47:46
node01 Keepalived_healthcheckers[3173]: Using LinkWatch kernel netlink reflector...
Oct 30 22:47:46
node01 Keepalived_healthcheckers[3173]: Activating healthchecker  for  service
[192.168.10.71]:3306
Oct 30 22:47:46
node01 kernel: IPVS: [wrr] scheduler registered.
Oct 30 22:47:47
node01 Keepalived_vrrp[3174]: VRRP_Instance(VI_1) Transition to MASTER STATE
Oct 30 22:47:48
node01 Keepalived_vrrp[3174]: VRRP_Instance(VI_1) Entering MASTER STATE
Oct 30 22:47:48
node01 Keepalived_vrrp[3174]: VRRP_Instance(VI_1) setting protocol VIPs.
Oct 30 22:47:48
node01 Keepalived_vrrp[3174]: VRRP_Instance(VI_1) Sending gratuitous ARPs on
eth2  for  192.168.10.70
Oct 30 22:47:48
node01 Keepalived_healthcheckers[3173]: Netlink reflector reports IP
192.168.10.70 added

f82d2f3f61f33f3de74428d34b5ca2fc.png

8、观察node02的message日志,node02进入了BACKUP角色,VIP自然不会加上。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
[root@node02 ~] # tail -f /var/log/messages
Oct 30 22:48:54
node02 Keepalived[16633]: Starting Keepalived v1.2.7 (09 /26 ,2012)
Oct 30 22:48:54
node02 Keepalived[16634]: Starting Healthcheck child process, pid=16636
Oct 30 22:48:54
node02 Keepalived[16634]: Starting VRRP child process, pid=16637
Oct 30 22:48:54
node02 Keepalived_vrrp[16637]: Interface queue is empty
Oct 30 22:48:54
node02 Keepalived_healthcheckers[16636]: Interface queue is empty
Oct 30 22:48:54
node02 Keepalived_vrrp[16637]: Netlink reflector reports IP 192.168.10.72 added
Oct 30 22:48:54
node02 Keepalived_vrrp[16637]: Netlink reflector reports IP
fe80::250:56ff:fe34:ca7 added
Oct 30 22:48:54
node02 Keepalived_vrrp[16637]: Registering Kernel netlink reflector
Oct 30 22:48:54
node02 Keepalived_vrrp[16637]: Registering Kernel netlink  command  channel
Oct 30 22:48:54
node02 Keepalived_vrrp[16637]: Registering gratuitous ARP shared channel
Oct 30 22:48:54
node02 Keepalived_vrrp[16637]: Opening  file  '/etc/keepalived/keepalived.conf' .
Oct 30 22:48:54
node02 Keepalived_healthcheckers[16636]: Netlink reflector reports IP
192.168.10.72 added
Oct 30 22:48:54
node02 Keepalived_healthcheckers[16636]: Netlink reflector reports IP
fe80::250:56ff:fe34:ca7 added
Oct 30 22:48:54
node02 Keepalived_healthcheckers[16636]: Registering Kernel netlink reflector
Oct 30 22:48:54
node02 Keepalived_healthcheckers[16636]: Registering Kernel netlink  command  channel
Oct 30 22:48:54
node02 Keepalived_healthcheckers[16636]: Opening  file '/etc/keepalived/keepalived.conf' .
Oct 30 22:48:54
node02 Keepalived_healthcheckers[16636]: Configuration is using : 11988 Bytes
Oct 30 22:48:54
node02 Keepalived_vrrp[16637]: Configuration is using : 63337 Bytes
Oct 30 22:48:54
node02 Keepalived_vrrp[16637]: Using LinkWatch kernel netlink reflector...
Oct 30 22:48:54
node02 Keepalived_vrrp[16637]: VRRP_Instance(VI_1) Entering BACKUP STATE
Oct 30 22:48:54
node02 Keepalived_healthcheckers[16636]: Using LinkWatch kernel netlink reflector...
Oct 30 22:48:54
node02 Keepalived_vrrp[16637]: VRRP sockpool: [ifindex(2), proto(112),fd(10,11)]
Oct 30 22:48:54
node02 Keepalived_healthcheckers[16636]: Activating healthchecker  for
service [192.168.10.72]:3306

81fb4c434e7d7d7c7e3b6f751d61ae4c.png

9、测试vip是否可能用来登录mysql,由于此时vip在node01上,我们就在node02上使用vip来测试登录,可见是没有问题的

93410134b22a289434936b7aad2396f4.png



五、Mysql高可用测试

1、停止node01的mysql服务,3306端口自然不通,keepalived检测到3306端口不通后执行自杀脚本停止自身服务,VIP被移除释放出来

1
2
[root@node01 ~] # service mysql stop
Shutting down MySQL..                                     [  OK  ]

2、观察node01的messages日志可以明显看出整个过程,VIP也已经不见了

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
[root@node01 ~] # tail -f /var/log/messages
Oct 30 23:06:42
node01 Keepalived_healthcheckers[3173]: TCP connection to [192.168.10.71]:3306 failed !!!
Oct 30 23:06:42
node01 Keepalived_healthcheckers[3173]: Removing service [192.168.10.71]:3306
from VS [192.168.10.70]:3306
Oct 30 23:06:42
node01 Keepalived_healthcheckers[3173]: Executing [ /etc/keepalived/stopkeepalived .sh]
for  service [192.168.10.71]:3306  in  VS [192.168.10.70]:3306
Oct 30 23:06:42
node01 Keepalived_healthcheckers[3173]: Lost quorum 1-0=1 > 0  for  VS [192.168.10.70]:3306
Oct 30 23:06:42
node01 Keepalived_healthcheckers[3173]: SMTP connection ERROR to [192.168.200.1]:25.
Oct 30 23:06:42
node01 kernel: IPVS: __ip_vs_del_service: enter
Oct 30 23:06:42
node01 Keepalived[3171]: Stopping Keepalived v1.2.7 (09 /26 ,2012)
Oct 30 23:06:42
node01 Keepalived_vrrp[3174]: VRRP_Instance(VI_1) sending 0 priority
Oct 30 23:06:42
node01 Keepalived_vrrp[3174]: VRRP_Instance(VI_1) removing protocol VIPs.

3287d9f4a2a1725076da39521b107ae2.png

3、观察node02的messages日志,可以看到node02进入了MASTER角色,接管了VIP,VIP已经加上,从日志的时间看,切换的过程不过花了1秒,可说是秒级切换了。

1
2
3
4
5
6
7
8
9
10
11
12
[root@node02 ~] # tail -f /var/log/messages
Oct 30 23:06:42
node02 Keepalived_vrrp[16637]: VRRP_Instance(VI_1) Transition to MASTER STATE
Oct 30 23:06:43
node02 Keepalived_vrrp[16637]: VRRP_Instance(VI_1) Entering MASTER STATE
Oct 30 23:06:43
node02 Keepalived_vrrp[16637]: VRRP_Instance(VI_1) setting protocol VIPs.
Oct 30 23:06:43
node02 Keepalived_vrrp[16637]: VRRP_Instance(VI_1) Sending gratuitous ARPs
on eth3  for  192.168.10.70
Oct 30 23:06:43
node02 Keepalived_healthcheckers[16636]: Netlink reflector reports IP 192.168.10.70 added

c148c7cc251fc6a63f07263528969903.png

由于node01的keepalived进程被自杀脚本停止了,因此需要手动启动。之前我想是否需要跑一个监控脚本把keepalived服务自动开起来呢,后来我觉得不必要,因为如果mysql的服务依然异常,就算keepalived的服务起来了,它检测到本机的3306端口不通,还是会再次自杀。而既然mysql服务已经异常、端口都不通了,一般也是需要手动检查干预把mysql启动起来的,因此在mysql服务正常后再顺便手动起一下keepalived就好了。



本文转自Mr大表哥jianlong1990 博客,原文链接:    http://blog.51cto.com/jiangjianlong/1981994   如需转载请自行联系原作者


相关实践学习
如何快速连接云数据库RDS MySQL
本场景介绍如何通过阿里云数据管理服务DMS快速连接云数据库RDS MySQL,然后进行数据表的CRUD操作。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心,利用清洁计算为万物互联的新世界提供源源不断的能源动力,目前开服的区域包括中国(华北、华东、华南、香港)、新加坡、美国(美东、美西)、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程,来了解阿里云能够为你的业务带来哪些帮助     相关的阿里云产品:云服务器ECS 云服务器 ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
相关文章
|
1月前
|
负载均衡 算法 关系型数据库
大数据大厂之MySQL数据库课程设计:揭秘MySQL集群架构负载均衡核心算法:从理论到Java代码实战,让你的数据库性能飙升!
本文聚焦 MySQL 集群架构中的负载均衡算法,阐述其重要性。详细介绍轮询、加权轮询、最少连接、加权最少连接、随机、源地址哈希等常用算法,分析各自优缺点及适用场景。并提供 Java 语言代码实现示例,助力直观理解。文章结构清晰,语言通俗易懂,对理解和应用负载均衡算法具有实用价值和参考价值。
大数据大厂之MySQL数据库课程设计:揭秘MySQL集群架构负载均衡核心算法:从理论到Java代码实战,让你的数据库性能飙升!
|
1月前
|
监控 Linux 应用服务中间件
Linux多节点多硬盘部署MinIO:分布式MinIO集群部署指南搭建高可用架构实践
通过以上步骤,已成功基于已有的 MinIO 服务,扩展为一个 MinIO 集群。该集群具有高可用性和容错性,适合生产环境使用。如果有任何问题,请检查日志或参考MinIO 官方文档。作者联系方式vx:2743642415。
325 56
|
2月前
|
消息中间件 存储 设计模式
RocketMQ原理—5.高可用+高并发+高性能架构
本文主要从高可用架构、高并发架构、高性能架构三个方面来介绍RocketMQ的原理。
372 21
RocketMQ原理—5.高可用+高并发+高性能架构
|
2月前
|
负载均衡 算法 关系型数据库
大数据新视界--大数据大厂之MySQL数据库课程设计:MySQL集群架构负载均衡故障排除与解决方案
本文深入探讨 MySQL 集群架构负载均衡的常见故障及排除方法。涵盖请求分配不均、节点无法响应、负载均衡器故障等现象,介绍多种负载均衡算法及故障排除步骤,包括检查负载均衡器状态、调整算法、诊断修复节点故障等。还阐述了预防措施与确保系统稳定性的方法,如定期监控维护、备份恢复策略、团队协作与知识管理等。为确保 MySQL 数据库系统高可用性提供全面指导。
|
4月前
|
SQL 存储 缓存
MySQL的架构与SQL语句执行过程
MySQL架构分为Server层和存储引擎层,具有高度灵活性和可扩展性。Server层包括连接器、查询缓存(MySQL 8.0已移除)、分析器、优化器和执行器,负责处理SQL语句;存储引擎层负责数据的存储和读取,常见引擎有InnoDB、MyISAM和Memory。SQL执行过程涉及连接、解析、优化、执行和结果返回等步骤,本文详细讲解了一条SQL语句的完整执行过程。
169 3
|
4月前
|
存储 SQL 缓存
MySQL原理简介—2.InnoDB架构原理和执行流程
本文介绍了MySQL中更新语句的执行流程及其背后的机制,主要包括: 1. **更新语句的执行流程**:从SQL解析到执行器调用InnoDB存储引擎接口。 2. **Buffer Pool缓冲池**:缓存磁盘数据,减少磁盘I/O。 3. **Undo日志**:记录更新前的数据,支持事务回滚。 4. **Redo日志**:确保事务持久性,防止宕机导致的数据丢失。 5. **Binlog日志**:记录逻辑操作,用于数据恢复和主从复制。 6. **事务提交机制**:包括redo日志和binlog日志的刷盘策略,确保数据一致性。 7. **后台IO线程**:将内存中的脏数据异步刷入磁盘。
199 12
|
6月前
|
弹性计算 API 持续交付
后端服务架构的微服务化转型
本文旨在探讨后端服务从单体架构向微服务架构转型的过程,分析微服务架构的优势和面临的挑战。文章首先介绍单体架构的局限性,然后详细阐述微服务架构的核心概念及其在现代软件开发中的应用。通过对比两种架构,指出微服务化转型的必要性和实施策略。最后,讨论了微服务架构实施过程中可能遇到的问题及解决方案。
|
7月前
|
Cloud Native Devops 云计算
云计算的未来:云原生架构与微服务的革命####
【10月更文挑战第21天】 随着企业数字化转型的加速,云原生技术正迅速成为IT行业的新宠。本文深入探讨了云原生架构的核心理念、关键技术如容器化和微服务的优势,以及如何通过这些技术实现高效、灵活且可扩展的现代应用开发。我们将揭示云原生如何重塑软件开发流程,提升业务敏捷性,并探索其对企业IT架构的深远影响。 ####
163 3
|
2月前
|
Cloud Native Serverless 流计算
云原生时代的应用架构演进:从微服务到 Serverless 的阿里云实践
云原生技术正重塑企业数字化转型路径。阿里云作为亚太领先云服务商,提供完整云原生产品矩阵:容器服务ACK优化启动速度与镜像分发效率;MSE微服务引擎保障高可用性;ASM服务网格降低资源消耗;函数计算FC突破冷启动瓶颈;SAE重新定义PaaS边界;PolarDB数据库实现存储计算分离;DataWorks简化数据湖构建;Flink实时计算助力风控系统。这些技术已在多行业落地,推动效率提升与商业模式创新,助力企业在数字化浪潮中占据先机。
200 12
|
7月前
|
Cloud Native 安全 数据安全/隐私保护
云原生架构下的微服务治理与挑战####
随着云计算技术的飞速发展,云原生架构以其高效、灵活、可扩展的特性成为现代企业IT架构的首选。本文聚焦于云原生环境下的微服务治理问题,探讨其在促进业务敏捷性的同时所面临的挑战及应对策略。通过分析微服务拆分、服务间通信、故障隔离与恢复等关键环节,本文旨在为读者提供一个关于如何在云原生环境中有效实施微服务治理的全面视角,助力企业在数字化转型的道路上稳健前行。 ####

推荐镜像

更多