Mysql SQL/ Mysql 主从

Posted on October 7, 2023

SQL

基础理解:

描述一下增加的每一个SQL函数的功能和用途。对于每个函数，请给出一个使用场景和相应的SQL示例。

RPAD:

功能：在字符串的右边填充指定的字符，直到达到指定的长度。 用途：格式化输出，使字符串达到固定长度。 示例：将’abc’填充到长度5，使用’z’作为填充字符。

SELECT RPAD('abc', 5, 'z');
-- 输出: 'abczz'

RTRIM : 功能：从字符串的右边移除指定的字符。 用途：清理字符串数据。 示例：移除’abc ‘字符串右侧的空格。

SELECT RTRIM('abc   ');
-- 输出: 'abc'

LTRIM: 功能：从字符串的左边移除指定的字符。 用途：清理字符串数据。 示例：移除’ abc’字符串左侧的空格。

SELECT LTRIM('   abc');
-- 输出: 'abc'

STRCMP: 功能：比较两个字符串。 用途：字符串比较。 示例：比较字符串’abc’和’def’。

SELECT STRCMP('abc', 'def');
-- 输出: -1 (因为 'abc' < 'def')

CHAR_LENGTH: 功能：返回字符串的字符数。 用途：获取字符串长度。 示例：获取’hello’的长度。

SELECT CHAR_LENGTH('hello');
-- 输出: 5

IF:

功能：如果表达式为真，返回一个值，否则返回另一个值。 用途：条件选择。 示例：基于条件返回值。

SELECT IF(1=1, 'true', 'false');
-- 输出: 'true'

IFNULL: 功能：如果表达式为NULL，返回指定的值。 用途：处理NULL值。 示例：将NULL值替换为’default’。

SELECT IFNULL(NULL, 'default');
-- 输出: 'default'

CAST (提到的CAST_NCHAR可能是MySQL中的CAST):

功能：转换一个值为指定的数据类型。 用途：数据类型转换。 示例：将数字123转换为字符串。

SELECT CAST(123 AS CHAR);
-- 输出: '123'

MOD:

功能：返回除法的余数。 用途：计算余数。 示例：计算7除以3的余数。

SELECT MOD(7, 3);
-- 输出: 1

设计和实现:

是如何决定增加这些特定的SQL函数的？它们解决了什么具体的问题或需求？

性能优化：有时，通过Arana内置函数来处理某些操作比在应用级别进行处理更为高效。

请解释增加这些函数在数据库中间件中的实现细节。例如，对于CAST_NCHAR函数，它是如何进行类型转换的？有没有考虑到性能影响？这些函数在性能上有何表现？

在中间件中，CAST_NCHAR函数会首先解析输入值的类型。使用内部库来将输入值转换为NCHAR类型（或其他特定字符集的字符串类型）。 该函数可能需要处理各种边界情况，例如非法输入值、超出范围的值等。 最后，函数会返回转换后的值。

当增加新的函数时，需要对其进行性能测试，确保它不会成为瓶颈。 例如，字符串操作函数（如RPAD或LTRIM）在处理大量数据时可能会有性能影响。但由于这些操作通常是内存中进行的，它们的性能通常相对较好。 CAST_NCHAR等类型转换函数可能会有更多的性能开销，特别是当涉及到大数据集时。但在很多情况下，由于转换操作通常是必要的，因此这种性能开销是可以接受的。

测试和验证:

是如何测试这些新增函数的功能和性能的？ 是否有遇到任何边缘情况或者异常情况？如何处理的？

应用和兼容性:

这些新增的SQL函数是否与其他数据库系统（如MySQL, Oracle等）的同名函数保持一致？

是的，为了保证开发者易于上手和一致性，我尽量让这些函数的行为与流行的数据库系统（如MySQL、Oracle等）中的同名函数保持一致。当然，我也查阅了各个数据库的官方文档来确认具体的行为和特征。

如何确保这些新增函数不会影响到现有的功能或引入新的问题？ 在添加新功能之前，我首先为现有的功能编写了详细的单元测试和集成测试。之后，为新的SQL函数添加了对应的测试用例。确保新的更改不会破坏现有的功能。 同时，进行代码审查，让团队成员评估并提供反馈。

知识和扩展:

描述IF和IFNULL的区别。

IF是一个条件函数，它接受三个参数：一个条件和两个结果值。如果条件为真，则返回第二个参数，否则返回第三个参数。示例：IF(1=1, ‘true’, ‘false’)返回true。 IFNULL若接受两个参数，它会检查第一个参数是否为NULL，如果是，则返回第二个参数，否则返回第一个参数。 示例：IFNULL(NULL, ‘default’)返回default。

如果让优化STRCMP函数，会有什么思路？

如何确保CAST_NCHAR函数在不同的字符集之间都可以正常工作？

针对不同的字符集进行详细的测试。 使用已有的字符集转换库，如ICU，确保转换的准确性。 提供一个配置选项，让用户选择源和目标字符集。

对于涉及浮点数的操作，会使用一定的精度或者epsilon来处理计算中的微小工件。提供一个配置项让用户选择计算精度。

实际应用场景:

描述一个实际应用中使用MOD函数来解决问题的例子。 RPAD和LTRIM在实际数据库设计中有哪些常见的用途？

深入问题:

如果的数据库中间件是分布式的，如何确保这些函数在所有节点上都有一致的表现？ 如何处理可能的浮点误差，例如在MOD函数中？

实际应用

MYSQL MOD函数实际应用例子：

场景：假设一个电商网站需要对用户进行分类处理，使得每个用户根据其用户ID可以被均匀地分配到10个不同的处理服务器上。

解决方案：可以使用MOD函数配合用户ID来决定每个用户应该去到哪个服务器。

SELECT user_id, MOD(user_id, 10) as server_allocation 
FROM users;

在这个例子中，MOD函数将每个user_id除以10，然后返回余数。因此，所有user_id的余数为0的用户将被分配到第一个服务器，余数为1的用户将被分配到第二个服务器，以此类推，直到余数为9的用户被分配到第十个服务器。

RPAD和LTRIM的实际应用：

RPAD（Right Padding）:

文本对齐：在生成报告或输出时，为了确保数据列的美观，您可能需要确保每个字符串都有相同的长度。例如，当在一个固定宽度的列中显示名称时，可以使用RPAD来确保每个名称都有相同的长度。

SELECT RPAD(customer_name, 20) as FormattedName 
FROM customers;

生成固定长度的记录：在某些文件格式或数据交换格式中，每条记录的长度都需要是固定的。使用RPAD可以确保每条记录都被填充到所需的长度。

LTRIM（Left Trim）:

清理数据：在导入外部数据或处理用户输入时，有时候数据的左侧会有不需要的空格。LTRIM可以用来去除这些不需要的前导空格。

SELECT LTRIM(product_name) as CleanedProductName 
FROM products;

特定格式的数据处理：在处理特定格式的字符串数据时，比如编码或序列号，如果它们有前导的特定字符（如’0’），LTRIM可以用来去除这些字符。

SELECT LTRIM(credit_card_number, '0') as CleanedCardNumber 
FROM transactions;

这两个函数在数据库设计中常被用于数据清洗、格式化输出和确保数据的一致性。

官方例子

https://dev.mysql.com/doc/refman/8.0/en/flow-control-functions.html#function_ifnull

RPAD:

使用：将字符串填充到指定的长度，超出长度的部分将被截断。

SELECT RPAD('hello', 10, '!');
输出：'hello!!!!!'

实现思路：检查输入字符串的长度，与期望的长度比较，然后重复添加填充字符直到达到期望的长度。

RTRIM:

使用：去除字符串右侧的空格。

SELECT RTRIM('hello   ');
输出：'hello'

实现思路：从字符串的末尾开始，删除每个空格字符，直到遇到非空格字符为止。

LTRIM:

使用：去除字符串左侧的空格。

SELECT LTRIM('   hello');
输出：'hello'

实现思路：从字符串的开头开始，删除每个空格字符，直到遇到非空格字符为止。

STRCMP:

使用：比较两个字符串，如果它们相同则返回0，如果第一个参数小于第二个参数则返回-1，否则返回1。

SELECT STRCMP('hello', 'world');
输出：-1

实现思路：按字典顺序逐字符比较两个字符串。

CHAR_LENGTH:

使用：返回字符串的长度。

SELECT CHAR_LENGTH('hello');
输出：5
实现思路：遍历字符串并计数。

IF:

使用：根据条件返回两个值之一。

SELECT IF(1 > 2, 'True', 'False');
输出：'False'

实现思路：评估第一个参数（条件），如果为真，则返回第二个参数的值，否则返回第三个参数的值。

IFNULL:

使用：检查第一个参数是否为NULL，如果是则返回第二个参数的值，否则返回第一个参数的值。

SELECT IFNULL(NULL, 'default');
输出：'default'
实现思路：检查第一个参数是否为NULL，然后相应地返回值。

CAST_NCHAR 假设它与MySQL中的CAST类似:

使用：将一个值转换为一个特定的数据类型。

SELECT CAST('12345' AS UNSIGNED);
输出：12345

实现思路：根据目标数据类型解析输入值。

MOD: 使用：返回除法的余数。

SELECT MOD(29, 9);
输出：2
实现思路：执行整数除法并返回余数。

主从

基础概念：

请解释MySQL主从复制的基本工作原理。

MySQL主从复制原理：主从复制允许数据从一个MySQL数据库服务器（称为主服务器）复制到一个或多个MySQL数据库服务器（称为从服务器）。主服务器写入变更到二进制日志（Binary Log），这些日志记录了数据更改。从服务器复制这些日志文件并执行这些日志中的事件来重做数据更改。

描述主从复制中的Binary Log和Relay Log

Binary Log和Relay Log：Binary Log是主服务器上的日志，记录了数据库上所有写操作的日志。从服务器首先将这些日志复制到Relay Log中，然后执行这些日志来更新它自己的数据。Relay Log就像一个缓冲区，保留从主服务器复制来的日志，直到从服务器已经应用了它们。

主从复制有哪几种模式？如同步复制和异步复制的区别是什么？以及如何配置和设置：

复制模式：主从复制主要有异步复制和半同步复制。

异步复制：主服务器执行事务并将事件记录到Binary Log，而不等待任何从服务器确认已经接收和存储了日志事件。

半同步复制：主服务器只有在至少有一个从服务器已经接收到并确认了写入其Relay Log的日志事件后，才会提交事务。

配置和设置：

描述设置主从复制的步骤

配置my.cnf文件：在主服务器中，需要启用log-bin选项来启动Binary Log和设置server-id。在从服务器中，需要设置relay-log，server-id和主服务器的连接详情，如master-host, master-user等。

Binary Log文件被删除：最安全的方法是从主服务器创建一个新的数据快照，然后在从服务器上重新启动复制过程。

故障和恢复：

如果从服务器落后主服务器很多，怎样进行同步？

可以暂停主服务器上的写入，等待从服务器赶上，或者重新从主服务器创建一个数据快照并在从服务器上重置复制。

当主服务器宕机时，如何提升一个从服务器为新的主服务器？

首先，选择一个最新的从服务器（最小的复制延迟）。然后，将这个从服务器提升为新的主服务器，并重新配置其他从服务器来复制这个新的主服务器。

如何检测和处理复制延迟？

检测和处理复制延迟：可以使用SHOW SLAVE STATUS命令来查看复制的状态和延迟。如果存在延迟，需要诊断网络问题，主服务器的写入负载，或从服务器的读取/写入负载

优化和性能：

如何优化主从复制的性能？

可以通过多线程复制、日志压缩、使用更快的硬件和网络来优化复制性能。

当有多个从服务器时，如何分发读取请求以均衡负载？

可以使用负载均衡器或代理来将读请求分发到多个从服务器。

安全性：

如何保证在主从复制中的数据传输的安全性？

数据传输安全：可以使用SSL加密复制流量。

如何设置主从复制中的用户权限？

用户权限：为复制设置一个专用的MySQL用户，并给予该用户只读取Binary Log的权限。

高级主题：

描述半同步复制和GTID复制。

GTID（全局事务ID）是MySQL的一种方式，为每个事务提供了一个唯一的ID，这简化了复制和故障恢复的过程。

如何在主从复制中实现数据的过滤和转换？

数据过滤和转换：可以使用–replicate-do-db, –replicate-ignore-db等选项来过滤复制的数据。

如何看待多源复制？

多源复制允许一个从服务器从多个主服务器复制数据。这在复杂的复制拓扑中非常有用。

实践经验

描述一个曾经遇到的关于主从复制的问题及其解决方法。

曾遇到过由于网络中断导致的复制延迟问题。解决方法是优化网络并为复制设置更大的超时时间。

如何监控复制的健康状态和性能？

可以使用SHOW SLAVE STATUS命令、Performance Schema或第三方工具如Percona Monitoring and Management (PMM)。

扩展性和其他相关技术：

与主从复制相比，您如何看待MySQL Group Replication和Galera Cluster？ 如果要构建一个高可用的MySQL集群，您会如何设计？

分布式系统基础

基本的分布式原理，如CAP定理、分布式锁、一致性算法如Paxos、Raft。

CAP定理：

定义：CAP定理是分布式计算系统中的一个基本原则，它表示任何分布式数据存储系统最多只能同时满足以下三个特性中的两个：一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）。 例子：在分布式数据库中，如果网络分区发生，系统必须在保持数据一致性和保持高可用性之间做出选择。 Cassandra：牺牲一致性以获得可用性和分区容错性。 HBase：牺牲可用性以获得一致性和分区容错性。

分布式锁：

定义：分布式锁是一种在分布式环境中确保资源单一访问的机制。由于在分布式系统中，多个节点可能同时尝试访问同一资源，所以需要一种机制来确保在同一时刻只有一个节点能够访问。

例子：使用Zookeeper或Redis来实现分布式锁。例如，应用程序可以使用Zookeeper的临时顺序节点来竞争获取锁。

  • 当一个客户端尝试获得锁时，它在一个指定的ZNode下创建一个临时顺序节点。
  • 客户端获取ZNode下所有子节点的列表，并检查自己创建的节点是否是序列号最小的节点。
  • 如果它创建的是最小的节点，那么它就成功获取了锁。如果不是，它则监听前一个（序列号比它小的）节点的删除事件。
  • 当前一个节点被删除（即释放锁）时，客户端再次尝试获取锁。
package main

import (
	"fmt"
	"log"
	"strings"

	"github.com/go-zookeeper/zk"
)

const LockNode = "/my-lock-"

func tryAcquireLock(conn *zk.Conn) (string, bool) {
	// 创建临时顺序节点
	path, err := conn.CreateProtectedEphemeralSequential(LockNode, []byte{}, zk.WorldACL(zk.PermAll))
	if err != nil {
		log.Fatalf("Failed to create lock node: %v", err)
	}

	// 获取所有子节点
	children, _, err := conn.Children("/")
	if err != nil {
		log.Fatalf("Failed to get children for root node: %v", err)
	}

	// 判断当前节点是否是最小节点
	minNode := path
	for _, child := range children {
		if strings.HasPrefix(child, LockNode) && child < minNode {
			minNode = child
		}
	}

	return path, minNode == path
}

func main() {
	conn, _, err := zk.Connect([]string{"127.0.0.1:2181"}, zk.DefaultSessionTimeout)
	if err != nil {
		log.Fatalf("Failed to connect to ZooKeeper: %v", err)
	}
	defer conn.Close()

	path, acquired := tryAcquireLock(conn)
	if acquired {
		fmt.Println("Lock acquired!")
		// Do the critical work
		conn.Delete(path, -1) // Release the lock
	} else {
		fmt.Println("Failed to acquire lock, waiting...")
		// Watch for the lock release or other event
	}
}
一致性算法：

Paxos： 定义：Paxos是一个解决分布式系统中的一致性问题的算法。它旨在确保分布式系统中的多数节点达成一致。 例子：Google的Chubby锁服务使用Paxos来确保一致性。

Raft： 定义：Raft是一个为分布式系统设计的一致性算法，它的目标是提供与Paxos相同的功能，但更加简单和易于理解。 例子：etcd和Consul等系统使用Raft来保持多节点间的一致性。

请描述Raft算法的基本工作原理。

Raft是一个为分布式系统提供强一致性的算法。其主要包括领导者选举、日志复制和安全性三个子问题。在任何时候，一个Raft集群中的所有节点都处于三种状态之一：Leader、Follower或Candidate。

Raft算法如何解决分布式系统的一致性问题？

Raft通过领导者选举来确保在任何时候只有一个领导者，这避免了冲突写入。所有的写操作首先发送给领导者，领导者将其写入日志并复制到其他的Follower上。

选举过程：

在Raft中，当一个节点想要成为领导者时，它如何启动选举过程？

当Follower在选举超时时间内没有接收到领导者的心跳，它就会变成Candidate并启动新的选举。它会增加当前的任期并为自己投票，然后向其他节点发送请求投票的消息。

如果在选举过程中收到了另一个节点的心跳，那么该如何处理？

如果在选举过程中，节点收到来自新的领导者的心跳，那么它会立即停止选举并回到Follower状态。

如果有多个候选者同时开始选举，Raft如何解决选举冲突？

如果多个候选者同时开始选举，可能没有候选者能获得多数的票数。如果发生这种情况，选举将失败并很快重新开始。由于每个候选者的选举超时时间是随机的，所以很少会有多次连续的冲突。

日志复制：

描述Raft中的日志复制过程。领导者如何确保所有的跟随者都复制了相同的日志条目？

当领导者收到客户端的写请求时，它首先将日志条目添加到自己的日志中。然后，它发送AppendEntries消息给其他所有的Follower来复制这个日志条目。当日志条目被多数的节点复制时，这个日志条目就被认为是提交的。

当跟随者落后或日志不一致时，领导者应该如何处理？

领导者会保存每个Follower的日志信息。如果发现Follower的日志与领导者不一致，它会找到最后一致的日志条目，然后发送所有之后的日志条目给这个Follower。

持久性与安全性：

在Raft中，为什么节点在投票或添加日志之前需要首先持久化其状态？

持久化状态（如日志条目和任期信息）是为了在节点重启后能保持和集群中的其他节点一致性，避免数据丢失或冲突。

如果某个节点的数据损坏或丢失，该如何恢复？

如果某个节点的数据损坏，它应该从领导者重新同步日志。在Raft协议中，领导者总是有最新的数据，因此可以作为数据源来同步其他的节点。

etcd和Consul的应用：

除了使用Raft实现一致性外，etcd和Consul在设计上还有哪些特点？

etcd提供了一个键值存储系统，它常被用作Kubernetes的配置中心。Consul除了键值存储外，还提供了服务发现和健康检查的功能。

etcd: 它是一个强一致性的键值存储系统，常被用作Kubernetes的配置中心。 提供了对于TTL（Time To Live）的原生支持，这对于服务发现非常有用。 提供了多版本并发控制 (MVCC) 功能，允许查询旧版本的数据。

Consul: 除了键值存储外，Consul提供了服务发现和健康检查功能。 支持多数据中心，非常适合大规模的基础架构。 提供了一个功能丰富的UI，允许运维人员查看和修改服务和键值信息。

  • 安装 Consul

首先，需要从Consul的官方网站下载合适的二进制文件。在Linux系统上，可以使用以下命令下载并解压：

wget https://releases.hashicorp.com/consul/1.10.1/consul_1.10.1_linux_amd64.zip
unzip consul_1.10.1_linux_amd64.zip
sudo mv consul /usr/local/bin/

Consul的使用：

  • 启动Consul agent

为简单起见，我们将在开发模式下启动Consul，这对于学习和开发很有用：

consul agent -dev
  • 使用Consul的KV存储

通过Consul的HTTP API或UI来操作KV存储。

使用HTTP API:

设置键值：

curl -X PUT -d 'Hello Consul' http://localhost:8500/v1/kv/mykey

查询键值：

curl http://localhost:8500/v1/kv/mykey?raw

使用UI:

打开浏览器并访问 http://localhost:8500/ui。在这里，可以看到一个直观的界面来管理键值对。

  1. 服务发现

为了展示服务发现的功能，我们可以注册一个服务。创建一个名为 web-service.json 的文件，并填充以下内容：


{
  "ID": "web1",
  "Name": "web",
  "Tags": ["rails"],
  "Address": "127.0.0.1",
  "Port": 80,
  "Check": {
    "HTTP": "http://localhost:80/",
    "Interval": "10s"
  }
}

然后，使用以下命令注册服务：

curl --request PUT --data @web-service.json http://localhost:8500/v1/agent/service/register
  • 健康检查

在上面的服务定义中，我们已经为服务定义了一个HTTP健康检查，它将每10秒检查一次 http://localhost:80/。如果服务健康，它会出现在Consul的UI中，而且状态为绿色。如果有问题，它会变为红色。

Consul的多数据中心：

在大型的企业和组织中，为了业务的高可用性、灾备和客户访问速度等因素，通常会在多个地理位置（例如，美国、欧洲、亚洲）设立数据中心。这些数据中心间可能需要进行某些级别的数据和服务交互。Consul的多数据中心支持意味着可以在每个数据中心都运行一个Consul集群，但它们之间可以互相感知、交互和共享一些关键信息。

服务发现跨数据中心 - 如果一个数据中心的服务失败了，客户端可以发现并使用其他数据中心的服务。 网络效率 - 当本地数据中心的服务可用时，客户端通常首选本地数据中心，只在必要时才切换到远程数据中心。 简化配置 - 不需要为每个数据中心设置单独的服务发现和配置工具。

初始化 - 当在纽约的数据中心启动Consul时，可以将其配置为”纽约”数据中心，并告诉它如何找到伦敦和新加坡的数据中心。 服务注册 - 在纽约的数据中心有一个名为”web-api”的服务，它在伦敦的数据中心也有一个备份或同类服务。 服务发现 - 当纽约的应用程序需要”web-api”服务时，Consul首先会在纽约的数据中心寻找这个服务。如果这个服务在纽约出现问题，Consul会知道伦敦数据中心也有这个服务，并可以将请求路由到那里。 跨数据中心的健康检查 - 可以配置健康检查，不仅仅检查本地数据中心的服务，而且还可以检查远程数据中心的服务。

如何看待etcd与Consul的性能和使用场景上的差异？

etcd 通常被视为Kubernetes的最佳伴侣，主要因为它为Kubernetes提供了强一致性配置存储。当涉及到K8s集群的状态管理和服务发现时，etcd通常是首选。 Consul 则更像是一个全能的工具，它提供了服务发现、健康检查和多数据中心支持。因此，对于需要这些功能和想要一个集成的解决方案的组织来说，Consul可能是一个更好的选择。 从性能的角度来看，具体的差异会基于工作负载、集群大小和网络条件。但在大多数常见的使用场景下，两者的性能都是可接受的。

与Paxos相比，Raft有哪些优点和缺点？

与Paxos相比，Raft有哪些优点和缺点？

优点: 简单性：Raft的设计目标之一是使得算法更容易理解，这使得它相对容易实现。 更好的文档：Raft的论文非常详细，并专注于提供直观的理解。 缺点: 在某些特定的场景和配置下，Paxos可能会比Raft更高效，尤其是在高冲突的环境下。

为什么许多现代系统选择Raft作为其一致性算法，而不是Paxos？

Raft提供了与Paxos相同级别的安全性和效率，但其更简单、更直观的设计使得开发者更容易实现和维护。而Paxos，尽管同样强大，却因为它的复杂性而被认为难以正确实现。

实际操作与故障排除：

如果在etcd或Consul群集中，一个节点长时间未响应，会发生什么？如何诊断和解决这种问题？

如果一个节点长时间未响应，Raft协议会确保集群继续工作，只要大多数节点仍然可用。该节点可能会被视为“下线”，并不再参与到集群的决策中。 诊断可以从查看节点的日志开始，检查是否有网络问题或硬件故障。使用etcdctl或Consul的CLI和UI工具可以帮助确定集群的状态和问题所在。 解决问题可能包括重启节点、解决网络问题或恢复硬件。

请描述一次在生产环境中遇到的与Raft或etcd/Consul相关的问题，以及是如何解决的。

问题诊断：

我首先查看了etcd集群的健康状态。使用etcdctl cluster-health发现其中一个节点是不健康的。 通过查看该节点的日志，我发现了大量与”election lost”相关的日志条目，表明该节点试图成为领导者，但没有成功。

进一步的网络诊断显示，由于网络分区（网络闪断或短暂的连接问题），该节点与其他etcd节点之间的通信中断。 解决办法：

我首先尝试重启有问题的etcd节点，看是否能自动恢复。 在节点重启后，问题仍然存在。考虑到可能是持久化的数据问题，我决定从集群中移除这个有问题的节点，并添加一个新的节点。 为了避免未来的网络问题，我加强了我们的网络监控和警报，确保及时发现并解决类似的问题。

数据库知识

MySQL：

存储引擎： MySQL支持多种存储引擎，如InnoDB、MyISAM等。InnoDB支持事务处理，有行级锁定，支持外键；而MyISAM不支持事务。

查询优化：通过使用索引、执行计划，可以有效优化查询速度。EXPLAIN命令可以帮助理解查询的执行路径。

事务处理： InnoDB支持ACID事务特性，保证数据的一致性、完整性。

数据库：

存储机制：以多版本并发控制（MVCC）方式处理数据，有利于多用户并发操作。

查询优化：提供了索引（包括JSON字段）、物化视图等，还有强大的查询优化器。

事务处理：支持ACID事务特性，可以处理复杂的事务需求。

MySQL的InnoDB存储引擎中MVCC的实现：

Undo日志 MVCC通过使用Undo日志实现。当一行数据被修改时，InnoDB会保存这行数据修改前的副本。新数据会被直接更新到表中，而旧数据则保存在Undo日志中。这样，当其他事务需要访问该行数据的旧版本时，它们可以直接从Undo日志中读取。（当事务需要读取数据但最新版本的数据对该事务不可见时（由于隔离级别或事务时间戳等原因），它会从Undo日志中读取相应的旧版本。）

读取视图（Read View） 为了确定某个事务中可以看到哪些数据版本，InnoDB为每个事务生成一个称为“读取视图”的结构。读取视图记录了哪些事务在该事务开始之后是活动的，因此它们修改的数据版本对当前事务是不可见的。

低限事务ID (low_limit_id): 这是读取视图创建时活动事务中的最大事务ID。这个ID之后开始的事务都是对当前事务不可见的。

上限事务ID (up_limit_id): 这是读取视图创建时活动事务中的最小事务ID。比这个ID更早的已完成事务的更改都被认为是持久化的，并且对当前事务是可见的。

事务ID数组 (trx_ids): 这是一个列表，包含在读取视图创建时正在进行的所有事务的事务ID。这些事务的更改对当前事务是不可见的。

当事务需要决定一个数据行是否可见时，它会使用读取视图进行以下检查：

如果行的创建版本号大于低限事务ID，则该行对事务不可见。 如果行的创建版本号小于上限事务ID或属于事务ID数组，则该行对事务可见。 如果行的删除版本号定义了并且小于低限事务ID，则该行对事务不可见。 如果行的删除版本号定义了并且大于上限事务ID或属于事务ID数组，则该行对事务可见。

系统版本号和事务版本号 InnoDB为每个新事务分配一个递增的事务ID，每行数据也都有两个额外的系统版本号：创建版本号和删除版本号（对于活动的行，删除版本号是未定义的）。创建版本号：当一行数据被插入或更新时，它的创建版本号被设置为进行该操作的事务的事务ID。这意味着这一行是由这个特定事务创建或最后更新的。删除版本号：当一行数据被删除时，它的删除版本号被设置为执行删除操作的事务的事务ID。这意味着这一行数据被这个特定事务标记为删除。

  1. 读取的隔离性 由于MVCC的这种机制，不同的事务可以看到同一行数据的不同版本，这保证了每个事务都能看到一个一致的数据视图，从而实现了各种隔离级别下的并发控制。例如，在“可重复读”隔离级别下，事务在其整个生命周期中总是看到数据的一个一致的版本，即使其他事务在此期间对数据进行了修改。

  2. 垃圾收集 随着时间的推移，Undo日志中的旧数据版本可能不再被任何事务所需要。InnoDB有一个背景进程会周期性地检查和清除这些不再需要的旧版本数据，以回收存储空间。

总之，通过保存数据的多个版本，并为每个事务提供一个一致的数据视图，MVCC允许多个读写事务并发执行，而不会相互阻塞，从而提供了高性能的并发控制。

InnoDB 的 MVCC（多版本并发控制）实现确实使用了创建版本号和删除版本号来支持非阻塞读取和一致性视图，但这些版本号并不是直接存储在用户可见的表空间中。因此，当您执行常规的 SELECT 查询时，您不会看到这些版本号。

按照数据在binlog中的记录方式把被封分类-基于语句的复制，基于行的复制

按照数据在binlog中的记录方式把备份分类-按照数据传输和数据一致性

异步复制 (Asynchronous Replication)：这是MySQL主从复制的默认模式。在这种模式下，主服务器上的事务一旦提交，就会立即返回给客户端，而不等待数据被复制到从服务器。这种方式的好处是低延迟和高吞吐量，但缺点是在主服务器出现故障时，数据可能还没被复制到从服务器，导致数据丢失。

半同步复制 (Semi-Synchronous Replication)：在这种模式下，主服务器会等待至少一个从服务器确认已经接收到了数据更改，然后才返回给客户端。这样确保了在主服务器出现故障时，至少有一个从服务器已经拥有最新的数据，降低了数据丢失的风险。然而，由于需要等待从服务器的确认，这会增加一些延迟。

同步复制 (Synchronous Replication)：在这种模式下，主服务器会等待所有的从服务器都确认接收到数据更改后才返回给客户端。这意味着所有的复制服务器都有完全相同的数据，确保了数据的一致性。但是，这种方法会大大增加延迟，因为需要等待所有从服务器的响应，而且对于跨地域的复制会有显著的性能影响。

异步复制 (Asynchronous Replication)

这是MySQL的默认模式，无需进行特殊配置。只需按照标准的主从复制配置即可。

半同步复制 (Semi-Synchronous Replication)

为了启用半同步复制，需要进行以下配置：

在主服务器和从服务器上安装半同步插件：

INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so';
INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so';

在my.cnf或my.ini文件中，对于主服务器：

[mysqld]
rpl_semi_sync_master_enabled = 1

对于从服务器：

[mysqld]
rpl_semi_sync_slave_enabled = 1

重新启动MySQL服务器以使设置生效。

同步复制 (Synchronous Replication)

注意：MySQL本身并不直接支持完全的同步复制，但可以通过Galera Cluster或其他第三方解决方案来实现。

对于MySQL，可以使用Galera Cluster实现同步复制。配置Galera Cluster比较复杂，需要进行以下几个主要步骤：

[mysqld]
binlog_format=ROW
default-storage-engine=innodb
innodb_autoinc_lock_mode=2
bind-address=0.0.0.0

# Galera Provider Configuration
wsrep_on=ON
wsrep_provider=/usr/lib/galera/libgalera_smm.so

# Galera Cluster Configuration
wsrep_cluster_name="test_cluster"
wsrep_cluster_address="gcomm://"

# Galera Node Configuration
wsrep_node_address="node1"
wsrep_node_name="node1"

# Galera Synchronization Configuration
wsrep_sst_method=rsync

[mysqld]
binlog_format=ROW
default-storage-engine=innodb
innodb_autoinc_lock_mode=2
bind-address=0.0.0.0

# Galera Provider Configuration
wsrep_on=ON
wsrep_provider=/usr/lib/galera/libgalera_smm.so

# Galera Cluster Configuration
wsrep_cluster_name="test_cluster"

wsrep_cluster_address="gcomm://node1"
wsrep_node_address="node2"
wsrep_node_name="node2"

wsrep_sst_method=rsync
                 

[mysqld]
binlog_format=ROW
default-storage-engine=innodb
innodb_autoinc_lock_mode=2
bind-address=0.0.0.0

# Galera Provider Configuration
wsrep_on=ON
wsrep_provider=/usr/lib/galera/libgalera_smm.so

# Galera Cluster Configuration
wsrep_cluster_name="test_cluster"

wsrep_cluster_address="gcomm://node1"
wsrep_node_address="node3"
wsrep_node_name="node3"

wsrep_sst_method=rsync                      

docker run --name node1 --network=galera_network -e MYSQL_ROOT_PASSWORD=rootpass -v ./galera-node1.cnf:/etc/mysql/mariadb.conf.d/galera.cnf -d mariadb:10.4 --wsrep-new-cluster
docker run --name node2 --network=galera_network -e MYSQL_ROOT_PASSWORD=rootpass -v ./galera-node2.cnf:/etc/mysql/mariadb.conf.d/galera.cnf -d mariadb:10.4
docker run --name node3 --network=galera_network -e MYSQL_ROOT_PASSWORD=rootpass -v ./galera-node3.cnf:/etc/mysql/mariadb.conf.d/galera.cnf -d mariadb:10.4

docker exec -it node1 mysql -uroot -prootpass -e "SHOW STATUS LIKE 'wsrep_cluster_size';"

不同的复制模式有不同的适用场景，选择最适合的复制模式需要考虑数据一致性需求、延迟、吞吐量以及系统复杂性等因素。

NoSQL数据库的理解

Redis： 特点： 内存中键值存储，提供数据持久化功能。 适用场景： 适用于需要快速读写的场景，如缓存、会话存储。

Redis如何做缓存以及会话存储？

Redis作为缓存： 原理： Redis的内存数据结构存储能力使其成为一个非常快速的存储系统，读写速度都非常快。这是因为所有数据都存储在内存中，并且Redis使用了高效的数据结构。

实践：

设置缓存：当应用程序需要缓存某些数据时（例如从数据库检索的结果），它可以先检查Redis中是否已有这些数据。如果没有，则从原始数据源检索数据，然后将数据放入Redis，并为其设置一个到期时间（TTL）。 获取缓存：当应用再次需要这些数据时，它首先会检查Redis。如果数据在Redis中并且未过期，应用可以直接从中读取，从而避免了向原始数据源的昂贵查询。 数据失效：通过设置TTL，旧的或不再需要的缓存数据会在一段时间后自动从Redis中删除，这样可以确保数据的相对新鲜性并释放内存空间。

Redis作为会话存储：

原理： 由于会话数据（例如用户登录状态、购物车内容、个人化设置等）通常需要快速读写，而且这些数据的生命周期通常与会话的生命周期相匹配，所以Redis是存储这些数据的理想选择。

实践：

会话创建：当用户登录或开始一个新的会话时，应用程序可以在Redis中创建一个新的记录，并使用唯一的会话ID作为键。 会话数据存取：在用户的会话过程中，应用程序可以快速地向Redis中的该会话ID对应的记录中添加、更新或删除数据。 会话结束：当用户注销或会话超时时，应用程序可以从Redis中删除该会话ID及其相关的数据。 持久性和备份：虽然会话数据通常是临时的，但在某些情况下，可能需要保留或备份这些数据。Redis提供了不同的持久性选项，如RDB快照和AOF日志，可以根据需要选择合适的持久性策略。

Cassandra相关知识

特点： 分布式、可扩展的NoSQL数据库，提供高可用性。 适用场景： 大规模数据存储，需要地理分布的场景。

基础知识： Apache Cassandra的主要特点： 分布式：可以水平扩展，没有单点故障。 支持高可用性和容错性。 列存储：适合写重型负载。 可调整的一致性模型。 支持复杂的查询。

保证高可用性和故障恢复：

数据在多个节点上进行复制，以防止任何节点故障。 Gossip协议用于节点发现和故障检测。 支持跨数据中心的复制，为地理冗余提供支持。

分区键和聚合键的区别： 分区键：确定数据在哪个节点上存储。 聚合键：在给定的分区中确定数据的排序。

定义复合主键：

使用分区键和一个或多个聚合键来定义。例如：PRIMARY KEY((partition_key), clustering_key1, clustering_key2)

Cassandra数据模型与RDBMS的不同： Cassandra使用列式存储，而传统的RDBMS使用行存储。 Cassandra不支持全表连接或复杂的多表连接。 数据模型设计是基于查询，而不是基于表结构。

架构和设计：

Cassandra的架构： 对等的节点架构，没有中心节点。 使用Gossip协议进行节点间通信。 数据分区并在多个节点上进行复制以保证冗余。

Gossip协议： 一种节点之间的通信协议，用于数据交换和故障检测。 Cassandra使用它来发现可用节点和不可用节点。 一致性级别： ONE：至少一个节点确认。 QUORUM：多数节点确认。 ALL：所有节点确认。 可以根据需要调整一致性级别来平衡性能和数据可靠性。 读写路径和写放大： 写操作首先写入CommitLog和Memtable。当Memtable满时，它被刷新到SSTable。 写放大是指一个写操作导致多个实际的磁盘写入操作。 SSTables与Memtables： Memtable是内存中的数据结构，存储最近的写操作。 SSTable是持久化的不可变的磁盘文件，代表了Memtable的一个快照。 高级主题： 数据去重： Cassandra使用时间戳来确定列值的版本。新的写操作将覆盖旧的值。 Hinted Handoff：

当目标节点不可用时，另一个节点将保存该数据，并在目标节点恢复时将其传递给它。 AP系统和CA特性：

根据CAP定理，Cassandra被认为是偏向可用性和分区容错性的AP系统。但在特定的配置下，例如使用ALL的一致性级别，它可能更接近CA。 修复过程：

使用nodetool repair进行数据同步和修复，确保数据在所有副本之间是一致的。 不支持跨行事务：

Cassandra的设计目标是高可用性和水平扩展，这与跨行事务的ACID属性相冲突。 性能和优化： 写入性能优化：

调整Memtable和CommitLog的配置。 使用合适的压缩和合并策略。 考虑查询模式：

在Cassandra中，数据模型设计是基于查询，而不是基于表结构。通常先确定查询，然后创建满足这些查询的数据模型。 Bloom Filter：

是一个空间效率的数据结构，用于测试一个元素是否是一个集合的成员，用于SSTables检查键是否存在。 节点崩溃或性能下降：

检查系统和GC日志。 使用nodetool进行状态和性能检查。 检查磁盘使用情况和网络问题。 实际经验和操作： Cassandra相关问题：

曾经遇到一个由于Java堆溢出引起的节点崩溃。通过增加JVM堆大小并调整GC设置来解决。 工具和库：

使用过nodetool进行集群管理，cqlsh进行查询，以及Cassandra Java驱动进行应用开发。 Lightweight Transactions：

是Cassandra中的条件更新，它们提供线性一致性。 备份和恢复数据：

使用nodetool snapshot进行备份，可以通过sstableloader或cqlsh进行数据恢复。 **监控和管理

MongoDB： 特点： 文档存储，支持JSON-like的数据格式。 适用场景： 当数据结构变化频繁时非常有用，例如，产品目录、内容管理系统等。

NewSQL数据库的概念和特点 NewSQL数据库是一类关系数据库管理系统，旨在提供可扩展的性能和ACID保证，与传统关系型数据库一样，但也具有能够匹配NoSQL系统的横向扩展性。

特点：

可扩展性： 提供和NoSQL相似的水平扩展能力。 关系模型： 依然使用关系模型，支持SQL查询。 完整事务支持： 提供完整的ACID事务特性。 一致性： 既能提供强一致性也能提供最终一致性，视具体实现和配置而定。

MYSQL的MVCC到底怎么实现的？

MVCC（多版本并发控制）是一种允许数据库在高并发情况下提供高性能读取的机制，它在多数流行的关系型数据库管理系统中，如MySQL的InnoDB存储引擎和PostgreSQL中，都有实现。MVCC允许数据的读取与写入操作在没有互相阻塞的情况下并发执行。

下面是MySQL的InnoDB存储引擎中MVCC的实现概述：

  1. Undo日志 MVCC通过使用Undo日志实现。当一行数据被修改时，InnoDB会保存这行数据修改前的副本。新数据会被直接更新到表中，而旧数据则保存在Undo日志中。这样，当其他事务需要访问该行数据的旧版本时，它们可以直接从Undo日志中读取。

  2. 读取视图（Read View） 为了确定某个事务中可以看到哪些数据版本，InnoDB为每个事务生成一个称为“读取视图”的结构。读取视图记录了哪些事务在该事务开始之后是活动的，因此它们修改的数据版本对当前事务是不可见的。

  3. 系统版本号和事务版本号 InnoDB为每个新事务分配一个递增的事务ID，并为每次插入或更新操作分配一个递增的系统版本号。每行数据也都有两个额外的系统版本号：创建版本号和删除版本号（对于活动的行，删除版本号是未定义的）。

当事务想要读取一行数据时，它会检查该行的创建版本号和删除版本号以确定是否可以看到这个版本的数据：

如果行的创建版本号大于事务的版本号，则该行在事务开始后创建，因此对事务不可见。 如果行的删除版本号已定义且小于或等于事务的版本号，则该行在事务开始之前就已被删除，因此对事务不可见。

  1. 读取的隔离性 由于MVCC的这种机制，不同的事务可以看到同一行数据的不同版本，这保证了每个事务都能看到一个一致的数据视图，从而实现了各种隔离级别下的并发控制。例如，在“可重复读”隔离级别下，事务在其整个生命周期中总是看到数据的一个一致的版本，即使其他事务在此期间对数据进行了修改。

  2. 垃圾收集 随着时间的推移，Undo日志中的旧数据版本可能不再被任何事务所需要。InnoDB有一个背景进程会周期性地检查和清除这些不再需要的旧版本数据，以回收存储空间。

总之，通过保存数据的多个版本，并为每个事务提供一个一致的数据视图，MVCC允许多个读写事务并发执行，而不会相互阻塞，从而提供了高性能的并发控制。

Tags: gin
Share: X (Twitter) Facebook LinkedIn