免费好用的MySQL高可用方案

最新推荐文章于 2023-10-03 18:20:51 发布
最新推荐文章于 2023-10-03 18:20:51 发布
阅读量400 收藏
点赞数
文章标签： 数据库 xhtml migration mycat redis
原文链接：https://ke.qq.com/course/2739691?saleToken=2208844\x26amp;from=pclink
版权

徐晨亮，MySQL DBA，知数堂学员。热衷于数据库优化，自动化运维及数据库周边工具开发，对MySQL源码有一定的兴趣。

环境说明
地址端口角色说明
127.0.0.13306master-
127.0.0.13307slave-
127.0.0.16032/6033ProxySQL版本2.0.1
127.0.0.110001replication-manager-

一、MySQL搭建

这里省略，推荐增强半同步
复制账号：repl/repl4slave

二、ProxySQL

2.1安装
[root@izbp12nspj47ypto9t6vyez src]# rpm -ivh proxysql-2.0.1-1-centos7.x86_64.rpm
Preparing...                          ################################# [100%]
Updating / installing...
   1:proxysql-2.0.1-1                 warning: group proxysql does not exist - using root
################################# [100%]
2.2用户配置

在master上创建连接账户及监控账户

grant select,update,delete,insert on *.* to xucl@'%' identified by 'xuclxucl';
grant replication client on *.* to monitor@'%' identified by 'monitor';
2.3server配置

w_hg : 10
ro_hg : 11

监控账号
monitor monitor

配置读写组

insert into mysql_replication_hostgroups(writer_hostgroup,reader_hostgroup) values(10,11);

配置MySQL实例

insert into mysql_servers(hostgroup_id,hostname,port,max_connections,max_replication_lag) values(10,'127.0.0.1',3306,100,300),(11,'127.0.0.1',3307,100,300);

配置USERS

insert into mysql_users(username,password,default_hostgroup,default_schema,max_connections) values('xucl','xuclxucl',10,'xucl',90);

配置监控账号

set mysql-monitor_username = 'monitor';
set mysql-monitor_password = 'monitor';
save mysql users to disk;
load mysql users to runtime;
save mysql servers to disk;
load mysql servers to runtime;
save mysql variables to disk;
load mysql variables to runtime;
2.4配置读写分离
INSERT INTO mysql_query_rules (rule_id,active,match_digest,destination_hostgroup,apply)
VALUES
(1,1,'^SELECT.*FOR UPDATE$',10,1),
(2,1,'^SELECT',11,1);
LOAD MYSQL QUERY RULES TO RUNTIME;
SAVE MYSQL QUERY RULES TO DISK;
2.5简单测试读写分离
(xucl:db1@xucl:09:29:57)[(none)]> select @@port;
+--------+
| @@port |
+--------+
|   3307 |
+--------+
1 row in set (0.05 sec)
(xucl:db1@xucl:09:30:00)[(none)]> select @@port for update;
+--------+
| @@port |
+--------+
|   3306 |
+--------+
1 row in set (0.00 sec)

三、replication-manager

3.1安装
rpm -ivh replication-manager-osc-2.0.0_rc2-1.x86_64.rpm
3.2配置文件
[root@izbp12nspj47ypto9t6vyez src]# cat /etc/replication-manager/config.toml
[db3306]
title = "db3306"
db-servers-hosts = "127.0.0.1:3306,127.0.0.1:3307"
db-servers-prefered-master = "127.0.0.1:3306"
db-servers-credential = "xucl:xuclxucl"
replication-credential = "repl:repl4slave"
failover-mode = "manual"
proxysql=true
proxysql-server="127.0.0.1"
proxysql-port=6033
proxysql-admin-port=6032
proxysql-writer-hostgroup=10
proxysql-reader-hostgroup=11
proxysql-user="admin"
proxysql-password="admin"
proxysql-bootstrap=false
[Default]
monitoring-datadir = "/data/replication-manager"
monitoring-sharedir = "/data/share_replication-manager"
log-level=7
log-file = "/var/log/replication-manager.log"
replication-multi-master = false
replication-multi-tier-slave = false
failover-readonly-state = true
http-server = true
http-bind-address = "0.0.0.0"
http-port = "10001"
3.3启动replication-manager
[root@izbp12nspj47ypto9t6vyez src]# service replication-manager restart
Restarting replication-manager (via systemctl):            [  OK  ]
日志
2019/02/22 09:34:38 [db3306] INFO  - Failover in interactive mode
2019/02/22 09:34:38 [db3306] INFO  - Loading 1 proxies
2019/02/22 09:34:38 [db3306] INFO  - Loading ProxySQL...
2019/02/22 09:34:38 [db3306] DEBUG - Monitoring server loop
2019/02/22 09:34:38 [db3306] DEBUG - Server [0]: URL: 127.0.0.1:3306  State: Suspect PrevState: Suspect
2019/02/22 09:34:38 [db3306] DEBUG - Server [1]: URL: 127.0.0.1:3307  State: Suspect PrevState: Suspect
2019/02/22 09:34:38 [db3306] DEBUG - State unconnected set by non-master rule on server 127.0.0.1:3307
2019/02/22 09:34:38 [db3306] DEBUG - Lookup server 127.0.0.1:3306 if maxscale binlog server: 127.0.0.1:3306
2019/02/22 09:34:38 [db3306] DEBUG - Lookup server 127.0.0.1:3307 if maxscale binlog server: 127.0.0.1:3306
2019/02/22 09:34:38 [db3306] DEBUG - Lookup server 127.0.0.1:3306 if maxscale binlog server: 127.0.0.1:3306
2019/02/22 09:34:38 [db3306] DEBUG - Lookup server 127.0.0.1:3307 if maxscale binlog server: 127.0.0.1:3306
2019/02/22 09:34:38 [db3306] DEBUG - GetMasterFromReplication server  3307  lookup if server 127.0.0.1:3307 is the one : 3307
2019/02/22 09:34:38 [db3306] DEBUG - Server 127.0.0.1:3306 is configured as a slave
2019/02/22 09:34:38 [db3306] DEBUG - Privilege check on 127.0.0.1:3306
2019/02/22 09:34:38 [db3306] DEBUG - Client connection found on server 127.0.0.1:3306 with IP 127.0.0.1 for host 127.0.0.1
2019/02/22 09:34:38 [db3306] DEBUG - Server 127.0.0.1:3307 was set master as last non slave
2019/02/22 09:34:38 [db3306] DEBUG - Privilege check on 127.0.0.1:3307
2019/02/22 09:34:38 [db3306] DEBUG - Client connection found on server 127.0.0.1:3307 with IP 127.0.0.1 for host 127.0.0.1
2019/02/22 09:34:38 [db3306] DEBUG - GetMasterFromReplication server  3307  lookup if server 127.0.0.1:3307 is the one : 3307
2019/02/22 09:34:38 [db3306] DEBUG - Checking if server 127.0.0.1 is a slave of server 127.0.0.1
2019/02/22 09:34:38 [db3306] DEBUG - GetMasterFromReplication server  3307  lookup if server 127.0.0.1:3307 is the one : 3307
2019/02/22 09:34:38 [db3306] INFO  - Init Proxy Type: proxysql Host: 127.0.0.1 Port: 6032
2019/02/22 09:34:38 [db3306] STATE - OPENED WARN0048 : No semisync settings on slave 127.0.0.1:3306
2019/02/22 09:34:38 [db3306] STATE - OPENED WARN0058 : No GTID strict mode on slave 127.0.0.1:3306
2019/02/22 09:34:38 [db3306] STATE - OPENED WARN0060 : No semisync settings on master 127.0.0.1:3307
2019/02/22 09:34:38 [db3306] STATE - OPENED WARN0070 : No GTID strict mode on master 127.0.0.1:3307
2019/02/22 09:34:38 [db3306] STATE - OPENED ERR00021 : All cluster db servers down
2019/02/22 09:34:38 [db3306] DEBUG - Lookup server 127.0.0.1:3306 if maxscale binlog server: 127.0.0.1:3306
2019/02/22 09:34:38 [db3306] DEBUG - Lookup server 127.0.0.1:3307 if maxscale binlog server: 127.0.0.1:3306
2019/02/22 09:34:39 [db3306] DEBUG - Lookup server 127.0.0.1:3306 if maxscale binlog server: 127.0.0.1:3306
2019/02/22 09:34:39 [db3306] DEBUG - Lookup server 127.0.0.1:3307 if maxscale binlog server: 127.0.0.1:3306
2019/02/22 09:34:39 [db3306] DEBUG - Lookup server 127.0.0.1:3306 if maxscale binlog server: 127.0.0.1:3306
2019/02/22 09:34:39 [db3306] DEBUG - Lookup server 127.0.0.1:3307 if maxscale binlog server: 127.0.0.1:3306
2019/02/22 09:34:40 [db3306] DEBUG - Lookup server 127.0.0.1:3306 if maxscale binlog server: 127.0.0.1:3306
2019/02/22 09:34:40 [db3306] DEBUG - Lookup server 127.0.0.1:3307 if maxscale binlog server: 127.0.0.1:3306
2019/02/22 09:34:40 [db3306] DEBUG - Lookup server 127.0.0.1:3306 if maxscale binlog server: 127.0.0.1:3306
2019/02/22 09:34:40 [db3306] DEBUG - Lookup server 127.0.0.1:3307 if maxscale binlog server: 127.0.0.1:3306
2019/02/22 09:34:40 [db3306] DEBUG - Monitoring server loop
2019/02/22 09:34:40 [db3306] DEBUG - Server [0]: URL: 127.0.0.1:3306  State:  Slave PrevState:  Slave
2019/02/22 09:34:40 [db3306] DEBUG - Server [1]: URL: 127.0.0.1:3307  State: Master PrevState: StandAlone
2019/02/22 09:34:40 [db3306] DEBUG - Master [ ]: URL: 127.0.0.1:3307  State: Master PrevState: StandAlone
2019/02/22 09:34:40 [db3306] DEBUG - Slave  [0]: URL: 127.0.0.1:3306  State:  Slave PrevState:  Slave
2019/02/22 09:34:40 [db3306] DEBUG - Server 127.0.0.1:3306 is configured as a slave
2019/02/22 09:34:40 [db3306] DEBUG - Privilege check on 127.0.0.1:3306
2019/02/22 09:34:40 [db3306] DEBUG - Client connection found on server 127.0.0.1:3306 with IP 127.0.0.1 for host 127.0.0.1
2019/02/22 09:34:40 [db3306] DEBUG - Server 127.0.0.1:3307 was set master as last non slave
2019/02/22 09:34:40 [db3306] DEBUG - Privilege check on 127.0.0.1:3307
2019/02/22 09:34:40 [db3306] DEBUG - Client connection found on server 127.0.0.1:3307 with IP 127.0.0.1 for host 127.0.0.1
2019/02/22 09:34:40 [db3306] DEBUG - GetMasterFromReplication server  3307  lookup if server 127.0.0.1:3307 is the one : 3307
2019/02/22 09:34:40 [db3306] DEBUG - Checking if server 127.0.0.1 is a slave of server 127.0.0.1
2019/02/22 09:34:40 [db3306] DEBUG - GetMasterFromReplication server  3307  lookup if server 127.0.0.1:3307 is the one : 3307
2019/02/22 09:34:40 [db3306] STATE - RESOLV ERR00021 : All cluster db servers down
2019/02/22 09:34:41 [db3306] DEBUG - Lookup server 127.0.0.1:3306 if maxscale binlog server: 127.0.0.1:3306
2019/02/22 09:34:41 [db3306] DEBUG - Lookup server 127.0.0.1:3307 if maxscale binlog server: 127.0.0.1:3306
2019/02/22 09:34:41 [db3306] DEBUG - Lookup server 127.0.0.1:3306 if maxscale binlog server: 127.0.0.1:3306
2019/02/22 09:34:41 [db3306] DEBUG - Lookup server 127.0.0.1:3307 if maxscale binlog server: 127.0.0.1:3306
2019/02/22 09:34:42 [db3306] DEBUG - Lookup server 127.0.0.1:3306 if maxscale binlog server: 127.0.0.1:3306
2019/02/22 09:34:42 [db3306] DEBUG - Lookup server 127.0.0.1:3307 if maxscale binlog server: 127.0.0.1:3306
2019/02/22 09:34:42 [db3306] DEBUG - Monitoring server loop
2019/02/22 09:34:42 [db3306] DEBUG - Server [0]: URL: 127.0.0.1:3306  State:  Slave PrevState:  Slave
2019/02/22 09:34:42 [db3306] DEBUG - Server [1]: URL: 127.0.0.1:3307  State: Master PrevState: Master
2019/02/22 09:34:42 [db3306] DEBUG - Master [ ]: URL: 127.0.0.1:3307  State: Master PrevState: Master
2019/02/22 09:34:42 [db3306] DEBUG - Slave  [0]: URL: 127.0.0.1:3306  State:  Slave PrevState:  Slave
2019/02/22 09:34:42 [db3306] DEBUG - Server 127.0.0.1:3306 is configured as a slave
2019/02/22 09:34:42 [db3306] DEBUG - Privilege check on 127.0.0.1:3306
2019/02/22 09:34:42 [db3306] DEBUG - Client connection found on server 127.0.0.1:3306 with IP 127.0.0.1 for host 127.0.0.1
2019/02/22 09:34:42 [db3306] DEBUG - Server 127.0.0.1:3307 was set master as last non slave
2019/02/22 09:34:42 [db3306] DEBUG - Privilege check on 127.0.0.1:3307
2019/02/22 09:34:42 [db3306] DEBUG - Client connection found on server 127.0.0.1:3307 with IP 127.0.0.1 for host 127.0.0.1
2019/02/22 09:34:42 [db3306] DEBUG - GetMasterFromReplication server  3307  lookup if server 127.0.0.1:3307 is the one : 3307
2019/02/22 09:34:42 [db3306] DEBUG - Checking if server 127.0.0.1 is a slave of server 127.0.0.1
2019/02/22 09:34:42 [db3306] DEBUG - GetMasterFromReplication server  3307  lookup if server 127.0.0.1:3307 is the one : 3307
2019/02/22 09:34:43 [db3306] DEBUG - Lookup server 127.0.0.1:3306 if maxscale binlog server: 127.0.0.1:3306
2019/02/22 09:34:43 [db3306] DEBUG - Lookup server 127.0.0.1:3307 if maxscale binlog server: 127.0.0.1:3306
3.4切换

手动点击switch over即可实现切换

切换日志

2019/02/22 09:38:22 [db3306] INFO  - Rest API receive Switchover request
2019/02/22 09:38:22 [db3306] INFO  - Signaling Switchover...
2019/02/22 09:38:22 [db3306] INFO  - --------------------------
2019/02/22 09:38:22 [db3306] INFO  - Starting master switchover
2019/02/22 09:38:22 [db3306] INFO  - --------------------------
2019/02/22 09:38:22 [db3306] INFO  - Checking long running updates on master 10
2019/02/22 09:38:22 [db3306] INFO  - Flushing tables on master 127.0.0.1:3307
2019/02/22 09:38:22 [db3306] INFO  - Electing a new master
2019/02/22 09:38:22 [db3306] INFO  - Slave 127.0.0.1:3306 has been elected as a new master
2019/02/22 09:38:22 [db3306] INFO  - Terminating all threads on 127.0.0.1:3307
2019/02/22 09:38:22 [db3306] INFO  - Rejecting updates on 127.0.0.1:3307 (old master)
2019/02/22 09:38:22 [db3306] INFO  - Waiting for candidate master to apply relay log
2019/02/22 09:38:22 [db3306] INFO  - Reading all relay logs on 127.0.0.1:3306
2019/02/22 09:38:22 [db3306] INFO  - Stopping slave thread on new master
2019/02/22 09:38:22 [db3306] INFO  - Failover Proxy Type: proxysql Host: 127.0.0.1 Port: 6032
2019/02/22 09:38:22 [db3306] INFO  - Resetting slave on new master and set read/write mode on
2019/02/22 09:38:22 [db3306] ERROR - Could not set new master as read-write
2019/02/22 09:38:22 [db3306] INFO  - Inject fake transaction on new master 127.0.0.1:3306
2019/02/22 09:38:22 [db3306] INFO  - Switching old master as a slave
2019/02/22 09:38:22 [db3306] INFO  - Doing MySQL GTID switch of the old master
2019/02/22 09:38:22 [db3306] INFO  - Switching other slaves to the new master
2019/02/22 09:38:22 [db3306] INFO  - Master switch on 127.0.0.1:3306 complete
2019/02/22 09:38:22 [db3306] STATE - OPENED ERR00041 : Skip slave in election 127.0.0.1:3307 has more than 30 seconds of replication delay (35484)
2019/02/22 09:38:22 [db3306] STATE - OPENED ERR00039 : Skip slave in election 127.0.0.1:3307 repl not electable
2019/02/22 09:38:22 [db3306] STATE - OPENED ERR00032 : No candidates found in slaves list
2019/02/22 09:38:34 [db3306] STATE - RESOLV ERR00041 : Skip slave in election 127.0.0.1:3307 has more than 30 seconds of replication delay (35481)
2019/02/22 09:38:34 [db3306] STATE - RESOLV ERR00039 : Skip slave in election 127.0.0.1:3307 repl not electable
2019/02/22 09:38:34 [db3306] STATE - RESOLV ERR00032 : No candidates found in slaves list

四、replication切换逻辑

在线切换逻辑

failover切换逻辑

总结

  • 总得来说这是一套简单又非常高效的MySQL高可用方案，并且是可上生产的方案，并且replication manager又自带web界面，操作起来非常简单

  • 这个方案前面有ProxySQL，可以实现读写分离，应用程序连接ProxySQL即可

  • replication manager负责数据库高可用切换，切换完成后，ProxySQL通过read only感知读写节点，对应用程序来说可能会有短暂的影响，确保程序重连机制

  • 看到replication manager的在线切换和failover切换逻辑，涉及到多个步骤的freeze，具体整个实现逻辑与过程将在下篇文章进行剖析

叶老师的「MySQL核心优化」大课已升级到MySQL 8.0，扫码开启MySQL 8.0修行之旅吧

老叶茶馆_
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
MySQL高可用方案大全
05-17
Lvs+Keepalived+MySQL 单点写入主主同步高可用方案 Lvs+Keepalived+MySQL 单点写入读负载均衡主主同步高可用方案 Heartbeat高可用MySQL主主同步方案 Heartbeat+DRBD+MySQL高可用方案 MMM高可用MySQL方案
MySql的高可用方案
JAVA技术爱好者
05-07 2637
MySql的高可用方案mysql架构的重要性一、MYSQL主从架构1.环境介绍2.搭建主从集群2.1.理论基础2.2 主从同步原理2.3.配置mysql主库（master）2.3.配置mysql从库（slave）2.4主从集群测试二、 集群搭建扩展1.全库同步与部分同步2.读写分离配置3.其他集群方式3.1互为主从的搭建3.2.GTID同步集群4.机器扩容三、半同步复制1.半同步复制2.搭建半同步复制集群四，主从架构的数据延迟问题五、MYSQL的高可用方案1、MMM2、MHA3、MGR六、分库分表1、分库分
最全面的MySQL高可用方案
老叶茶馆
09-29 5593
高可用是数据库永恒的话题，高可用方案也是最受数据库爱好者关注的重点技术之一。在MySQL二十多年的发展历程中，针对MySQL的高可用方案百花齐放，各具特色，这也是这款开源数据库最能让人着迷的地方。例如，早些年著名的MMM、MHA等等。随着MySQL官方的不断发力，在基于MySQL复制的基础上，推出了一系列的高可用方案，例如，主从半同步复制、InnoDB ReplicaSet、组复制（MGR）、In...
MySQL 常用高可用方案
AlbenXie的博客
11-14 7209
在使用 MGR 时，如果要实现完整的高可用方案，就需要用到 InnoDB Cluster。MHA（Master High Avaliable） 是一款 MySQL 开源高可用程序，MHA 在监测到主实例无响应后，可以自动将同步最靠前的 Slave 提升为 Master，然后将其他所有的 Slave 重新指向新的 Master。其大致原理是：在主实例的 Keepalived 中，增加监测本机 MySQL 是否存活的脚本，如果监测 MySQL 挂了，就会重启 Keepalived，从而使 VIP 飘到从实例。
五大常见的MySQL高可用方案(最全)
不积跬步，无以至千里；不积小流，无以成江海。
02-24 9681
1. 概述 我们在考虑MySQL数据库的高可用的架构时，主要要考虑如下几方面： 如果数据库发生了宕机或者意外中断等故障，能尽快恢复数据库的可用性，尽可能的减少停机时间，保证业务不会因为数据库的故障而中断。 用作备份、只读副本等功能的非主节点的数据应该和主节点的数据实时或者最终保持一致。 当业务发生数据库切换时，切换前后的数据库内容应当一致，不会因为数据缺失或者数据不一致而影响业务。 关于对高可用的分级在这里我们不做详细的讨论，这里只讨论常用高可用方案的优缺点以及高可用方案的选型。 2. 高可用方案 2.
详解MySQL高可用MMM搭建方案及架构原理
09-10
MySQL高可用MMM（Mysql-Multi-Master Replication Manager）是一种多主复制解决方案，它允许在多个MySQL主节点之间进行数据同步，以实现高可用性和负载均衡。然而，MMM并不适合那些对数据一致性有严格要求的业务场景...
MySQL高可用解决方案_社区 .pdf
11-05
MySQL解决方案工程师总结，MySQL高可用解决方案，全部使用MySQL官方社区版本。
五大常见的MySQL高可用方案
01-27
我们在考虑MySQL数据库的高可用的架构时，主要要考虑如下几方面：如果数据库发生了宕机或者意外中断等故障，能尽快恢复数据库的可用性，尽可能的减少停机时间，保证业务不会因为数据库的故障而中断。用作备份、只读...
MySQL数据库高可用性方案.pdf
12-02
方案拓扑图 主从复制拓扑图 首先必须打开Master端的binary log（bin-log） Slave Master端获取该日志然后再在自己身上完全顺序的执行 优缺点优点：易实施、成本低、经济
2-5、MySQL高可用架构演进-吴炳锡@知数堂.pdf
12-16
MySQL高可用架构演进-吴炳锡。 1. 什么是高可用 2. 第一代传统复制: MHA及使用架构 3. 第二代基于GTID复制:GTID+Binlog server At Booking & Facebook 4. 第三代增强半同步复制:GTID+增强半同步及多IDC架构及使用架构 5. 第四代MySQL原生高可用 : MySQL InnoDB Cluster 6. 高可用选择建议
Mysql的高可用方案及主从详细配置
勤能补拙
01-23 1815
1、常用的高可用MySQL解决方案： 数据库作为最基础的数据存储服务之一，在存储系统中有着非常重要的地位，因此要求其具备高可用性无可厚非。能实现不同SLA(服务水平协定)的解决方案有很多种，这些方案可以保证数据 库服务器在硬件或软件出现故障时服务继续可用。 高可用需要解决的主要问题有两个，一是如何实现数据共享或同步数据，另一个是如何处理failover。数据共享一般的解决方案是通过SAN（St
MySQL常见高可用方案
laowaizhangge的博客
02-12 2704
MySQL成熟的高可用解决方案比较多，业界广泛运用的包括M-S，MMM，MHA，MySQL Innodb Cluster，MySQL NDB Cluster，MGR，DRDB等，下面对这些方案按照所采用的核心技术进行分类，并对各自的优势和不足进行总结。 Category 1: MySQL原生异步，半同步或同步复制 这类方案主要是M-S(Master-Slave)以及其变体（如M-S-S，M-M ）以及 MGR ，它基于MySQL binlog的产生，传输，同步和解析。主节点产生binlog日志，其他节点获取
MySQL高可用方案选型参考
热门推荐
一个天秤座的架构师
03-31 2万+
高可用的意义以及各种不同高可用等级相应的停机时间我就不必多说了，直接进入主题。 可选MySQL高可用方案 MySQL的各种高可用方案，大多是基于以下几种基础来部署的： 基于主从复制； 基于Galera协议； 基于NDB引擎； 基于中间件/proxy； 基于共享存储； 基于主机高可用； 在这些可选项中，最常见的就是基于主从复制的方案，其次是基于Galera的方案，我们重点说说这两种方...
MySQL高可用九种方案
最新发布
meser88的博客
10-03 1676
需要注意的是，MHA 并不是万能的解决方案，它适用于大多数的 MySQL 数据库场景，但在特定的情况下可能需要根据实际需求进行定制化的配置和调整。在使用 Galera Cluster 之前，建议进行充分的测试和评估，以确保它能够满足系统的可用性、性能和扩展性要求，并根据具体的应用场景和需求进行适当的配置和调整。在使用 MySQL Cluster 之前，建议进行充分的测试和评估，以确保它能够满足系统的可用性、性能和扩展性要求，并根据具体的应用场景和需求进行适当的配置和调整。
MySQL第七讲 MySQL的高可用方案
程序员路同学
05-22 5511
MySQL第七讲 MySQL的高可用方案
《叶问》第19期
老叶茶馆
10-14 463
关 于 叶 问《叶问》是知数堂新设计的互动栏目，不定期给大家提供技术知识小贴士，形式不限，或提问、或讨论均可，并在当天发布答案，让大家轻轻松松利用碎片时间就可以学到最实用...
MySQL的高可用性方案有哪些？MySQL的字段类型如何选择和优化？MySQL的并发控制机制是怎样的？MySQL的全文搜索如何实现？
luoluoal的博客
07-07 409
避免使用TEXT或BLOB类型：TEXT和BLOB类型适用于存储大量的文本或二进制数据，但是这些类型的字段会增加查询的复杂性和性能消耗。选择合适的数据类型：根据数据的特性选择最合适的数据类型，可以减小数据存储的空间占用和提高查询效率。通过锁机制和事务隔离级别，MySQL可以实现并发控制，保证数据的一致性和并发性能的平衡。避免使用过大的数据类型：使用合适的数据类型可以减小数据存储的空间占用。选择和优化MySQL的字段类型是一个关键的决策，可以影响到数据库的性能和数据存储的有效性。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值