- 博客(49)
- 收藏
- 关注
RSS订阅原创 my2sql工具恢复误删数据
这些操作涉及数据的增删改，可以通过 binlog 中的旧值和新值进行回滚。这些操作涉及表结构的变更，无法通过 binlog 直接回滚。工具只能解析 DML 操作的 binlog，无法处理 DDL 操作。参数决定了 binlog 中是否记录完整的旧值和新值。如果需要回滚 DDL 操作，通常需要手动恢复（例如通过备份）。：在更新或删除操作之前，记录了完整的行数据。：在更新或插入操作之后，记录了完整的行数据。再进入/data/backup/test。：数据操作语言，包括。my2sql下载地址。
2025-04-11 16:51:28
520
原创 物理备份工具XtraBackup怎么备份数据
如果备份的是从库，该文件会记录主节点的位点信息，包括Relay_Master_Log_File和Exec_Master_Log_Pos。：记录了一些InnoDB引擎的参数，如innodb_data_home_dir、innodb_data_file_path等。：记录备份的类型（如全量备份或增量备份）和LSN（日志序列号）信息。：在准备备份阶段，用于将数据文件恢复到备份结束时的一致性状态。：记录备份的详细信息，包括备份时间、备份方式、备份目录等。：提供备份的元数据信息，方便在恢复时了解备份的背景和配置。
2025-04-08 13:29:14
426
原创 物理备份工具Xtrabackup备份和恢复原理详解
XtraBackup 能够在数据库运行时进行备份，无需停止数据库服务或锁定表。这使得备份过程对数据库的正常运行几乎没有影响，特别适合高负载的生产环境。：备份过程中不会打断正在进行的事务，确保数据的一致性，同时不影响数据库性能。：XtraBackup 采用物理备份方式，直接备份数据文件，而不是逻辑备份（如 mysqldump）。这种方式备份和恢复速度更快，特别适合大规模数据库。：支持基于时间点的增量备份，只备份自上次备份以来发生更改的数据，节省存储空间和备份时间。
2025-04-02 15:12:31
683
原创 mydumper细节上的用法
指定从上次更新的时间开始备份，单位为天。：指定需要备份的表名，多个表用逗号分隔。：使用正则表达式排除不需要备份的数据库。备份指定数据库中的某一张表，例如。：指定需要备份的数据库名称。：指定备份文件的输出目录。备份指定的数据库，例如。如果需要排除系统库（如。
2025-04-02 11:16:24
231
原创 多线程逻辑备份工具mydumper的备份和恢复原理
将所有当前打开的表刷新到磁盘上操作mydumper会执行命令，将所有当前打开的表刷新到磁盘上。目的：确保所有表的数据已经写入磁盘，避免数据丢失或不一致。SQL 语句。
2025-04-01 13:24:53
560
原创 详解回滚日志（Undo Log） 的相关配置
是 MySQL 中的一个配置参数，用于控制 Purge 系统释放回滚段（Rollback Segment）的频率。回滚段（rollback segment）是 InnoDB 中用于管理 undo log 的一种结构，每个回滚段可以支持一定数量的并发事务。是 MySQL InnoDB 存储引擎中的一个系统变量，用于定义每个 undo 表空间中分配的回滚段数量。每个回滚段支持的事务数量取决于 InnoDB 的页面大小（innodb_page_size）和每个事务所需的 undo log 数量。
2025-03-29 12:00:59
744
原创 回滚日志（Undo Log） 的 Purge
对于不同类型的undo log记录，判断是否可以被清理的方式也有所不同。例如，TRX_UNDO_DEL_MARK_REC类型的undo record对应的记录需要从索引上真正删除后，其对应的undo log才可以被清理。：系统会维护一个purge queue，其中按照事务提交顺序（trx_no）排序，确保先提交的事务对应的undo log先被处理。，说明该事务在所有读开始之前已经提交，其修改的新版本是可见的，因此不再需要通过undo构建之前的版本，这个事务的undo log就可以被清理了。
2025-03-26 16:37:29
411
1
原创 详解回滚日志（Undo Log）
当事务执行过程中出现问题，或被认为取消，需要将已经修改的操作恢复原状，这个时候MySQL会使用对应的undo log进行回滚操作，确保数据的一致性。也就是多版本并发控制，当用户读取一行记录时，如果这个事务已经被其他事务占用，那么当前事务可以通过undo log读取之前的行版本信息，以此实现非锁定读取，从而在一定程度上避免了读写冲突，提高了并发性能。在InnoDB存储引擎中，MVCC的实现依赖于undo log，它允许不同的事务读取到数据的不同版本，从而实现一致性的快照读。：唯一标识表中的每一行记录。
2025-03-21 12:00:27
576
原创 详细介绍MySQL分区
有一些表，我们需要定期删除掉历史的数据，如果采用delete会非常慢，并且有可能会导致从库延迟，我们就可以考虑分区，在删除数据时，针对特定的分区进行删除，而不影响其他的分区，可以提高管理和维护的效率。当表过大的时候，即使增加了索引，查询性能也不是很高，如果有了分区，查询相关数据时，可以只扫码必要的分区，可以让查询更快。如果分区字段为null，那么在范围分组中，这一行会被分区到最小的范围里。表分区之后，可以把不同的分区放在不同的磁盘上，这样可以存储更多的数据。存储引擎的分区表不支持外键。
2025-03-18 23:11:14
312
原创 MySQL配置多线程复制
不行，比如第一事务发给线程一，第二个事务发给线程二，其实是不行的，因为事务分开执行后，可能在从库出现第二个事务先执行完的情况，如果两个事务正好操作同一行，因为主库和从库的执行顺序不一样，就可能导致主从复制不一致。不行，比如这个事务更新了同一张表的不同行，如果两条语句分到不同的线程，假如某一行更新完成，另一行还没有更新，这个时候从库查询这张表的数据就会和主库不一致。：在WRITESET的基础上增加了一个约束，即在主库上同一线程（SESSION）先后执行的两个事务，在从库执行时也要保持相同的先后顺序。
2025-03-13 17:22:08
859
原创 MySQL快速搭建主从复制
这些参数描述了从服务器的 I/O 线程和 SQL 线程的运行状态。这些参数描述了从服务器正在复制的主服务器二进制日志文件和位置。配置从服务器（Slave）以连接到主服务器（Master）2、修改主从server_id（建议修改成IP的后两段）这些参数描述了从服务器与主服务器之间的同步延迟。这些参数描述了从服务器如何连接到主服务器。二、准备阶段(主库和从库配置都需要修改）这些参数描述了从服务器的中继日志状态。查看从服务器（Slave）复制状态。启动从服务器（Slave）的复制线程。1、创建用户（主库）
2025-03-03 21:34:36
816
原创 MySQL8.0 的重做日志（Redo Log）的归档
mysql在数据备份过程中，可能会复制RedoLog，如果这期间mysql频繁变更，那么复制RedoLog的速度，就跟不上RedoLog的生成速度，因为RedoLog是以覆盖方式记录的，就可能会丢失部分RedoLog。MySQL8.0.17引入了RedoLog归档，按照RedoLog顺序，写入归档文件中，来解决备份中RedoLog丢失等情况。的步骤，从而减少磁盘 I/O 操作，提高写入速度。在某些场景下，如大量数据导入，关闭。后，写入操作可以跳过记录。停止RedoLog归档。
2025-02-26 22:06:44
260
原创 详解中继日志（Relay Log）
当主服务器（Master）发生故障时，从服务器（Slave）可以通过中继日志快速恢复到故障前的状态，保证主从数据的一致性，从而降低数据丢失的风险，提高系统的可靠性。例如，原本频繁地将整个数据页落盘会带来大量的随机 IO，而有了中继日志，只需要将中继日志文件顺序落盘，就可以将随机 IO 转换为顺序 IO，提高写入效率，使数据库能够更好地处理大量的写入请求。当主服务器不可用时，从服务器可以根据中继日志中的数据变更记录，快速恢复并接管主服务器的服务，确保系统的持续运行，减少业务中断时间。
2025-02-26 13:54:38
774
原创 MySQL主从复制的底层原理
一、什么是MySQL的主从复制MySQL的主从复制（Master-Slave Replication）是一种数据库架构，它允许一个MySQL数据库（主服务器，Master）将数据复制到一个或多个MySQL数据库（从服务器，Slave）。这种机制主要用于实现数据的冗余备份、负载均衡、读写分离以及高可用性等目标。二、工作原理：记录所有数据变更操作（如INSERT、UPDATE、DELETE等）到二进制日志（Binary Log）中。
2025-02-26 09:27:51
294
原创 mysqldump细节上的用法
保留 GTID 信息的主要目的是为了确保主从复制的一致性和完整性。如果你的备份与主从复制相关，或者需要保留完整的事务历史，建议保留 GTID 信息。否则，可以使用来简化备份和恢复过程。2、备份多个库3、备份所有数据库4、备份某一张表先接库名test再接表名t15、备份多张表6、远程备份mysqldump -u'ccj' -p'ccj' -h'IP 地址' --set-gtid-purged=off taskflow >bak.sql7、添加删除语句。
2025-02-25 17:08:45
426
原创 逻辑备份工具mysqldump备份和恢复原理详解
获取数据库的元数据信息查看库里有哪些表给备份的表加读锁，允许其他会话在本地读取数据，但不允许修改查看表结构查看全表数据，备份表内容查看表上的所有触发器，备份触发器信息解锁，备份完成删除要导入的表（如果存在）重新创建要导入数据的表给表加写锁，读和写都不允许关闭表的索引写入备份数据打开表的索引解锁，恢复完成。
2025-02-25 14:16:38
142
原创 MySQL错误日志（ErrorLog）
是 MySQL 中用于控制错误日志详细程度的参数。：记录错误、警告和通知信息（Error, warning, and note messages）。：仅记录错误信息（Error messages）。这是最低级别，仅包含重要的错误事件。：记录错误和警告信息（Error and warning messages）。在MySQL中查看错误日志的路径。：具体描述问题或事件的详细信息。信息日志每分钟最多记录一条。查看配置文件my.cnf。2、错误任务的记录级别。3、错误日志的内容解析。：记录事件发生的时间。
2025-02-25 11:52:45
354
3
原创 MySQL慢查询日志（SlowLog）
该参数设置了一个查询必须检查的最小行数，只有达到或超过此值的查询才会被记录到慢查询日志中。这有助于过滤掉那些对性能影响较小的查询，专注于那些可能扫描大量数据的查询。但需要注意，启用后可能会显著增加日志的详细程度，尤其是对于繁忙的服务器。：启用该参数后，MySQL 会记录那些未使用索引的查询语句。：当启用该参数时，MySQL 会将慢的管理类语句记录到慢查询日志中。：通过设置较高的值，可以减少日志中的“噪声”，专注于那些真正可能影响性能的查询。设置的阈值，它们也会被记录到慢查询日志中。设置慢查询日志的路径。
2025-02-25 10:39:12
302
原创 详解MySQL查询日志（GeneralLog）
3、修改General Log的输出方式。添加general_log = on。，表示日志将保存在日志文件中；修改MySQL配置文件my.cnf。一、General Log的设置。查看GeneralLog是否开启。开启GeneralLog。，表示日志不会被记录。
2025-02-24 16:50:50
287
原创 MySQL二进制日志（Binlog）是如何落盘
MySQL 启动时会为分配一个，用于临时存储事务中的变更操作。每个线程独立管理自己的 Binlog 缓存（避免并发写入冲突）。此外，还有一个（内存队列），用于合并所有线程缓存的数据。当有数据变更操作（如）时：变更会先写入当前线程的。，该线程的 Binlog 缓存会被复制到。未提交的事务不会进入全局缓冲区（保证原子性）。全局缓冲区是所有线程共享的，用于后续批量写入磁盘。负责将全局 Binlog 缓冲区的数据写入磁盘文件。写入时机由参数控制。
2025-02-24 14:13:26
424
原创 MySQL清除无用的二进制日志（Binlog）
expire_logs_days已经在 MySQL 8.0 中被标记为。（deprecated），并计划在未来版本中被移除。2、删除指定binlog之前的文件。设置成功后，清除超过时间的日志。一、Binlog的清除方法。
2025-02-24 11:38:36
369
原创 MySQL的Binlog解析
重启MySQL后，查看binlog是否已经加密,Encrypted为yes则开启binlog加密。加密后则需要添加--read-from-remote-server -uroot -p。查看当前主服务器（Master）的二进制日志（Binary Log）状态。binlog加密，修改MySQL的配置文件my.cnf。解析某个库的binlog。
2025-02-24 10:40:32
259
原创 大表数据删除的优化
delete删除数据后，表的大小是没有变化的，因为delete删除某条记录时，innodb只是把记录的位置标记为已删除，如果之后要在该位置插入数据，就可以适用这个位置，如果一直没有数据插入，就会形成一个空洞，占用存储空间，因此delete命令是不能回收表空间的。2、避免使用delete，因为delete不会释放空间，如果单次delete过多的数据，还可能导致长时间的锁等待，如果binlog的格式是ROW格式，delete需要逐行删除，每一行都需要binlog，会导致binlog暴增，
2025-02-23 14:46:39
433
原创 数据导入优化
插入数据的时间分布连接 30%向服务器发送查询 20%解析查询 20%插入行 大概10%插入索引 大概10%结束 10%可以看出大多数时间消耗在客户端和服务端通信的时间上。
2025-02-15 11:56:11
238
原创 操作系统参数的优化
Deadline调度算法是一种以截止时间为驱动的IO调度策略，它通过分类管理读写请求和保证请求在一定时间内被服务，来优化IO性能，特别是在需要保证IO请求及时性的场合。IO是"Input/Output" 的缩写，指的是计算机系统中输入和输出的操作，在磁盘或者其他块设备的读取和写入操作。NOOP算法非常简单，它不进行任何复杂的调度操作，只是将IO请求放入队列中，然后按顺序执行。其主要目的是在多个进程竞争磁盘I/O时实现公平性，确保每个进程都能获得合理的I/O带宽。查看当前设备使用的IO调度算法。
2024-11-24 19:55:34
320
原创 硬件相关优化
MySQL面临高并发、低延迟的挑战，这个时候选择更多核心的CPU，相对于选择主频更高的CPU来说，带来的收益会更为的显著。多核心的处理器，能够更有效的处理大量并发请求，提高系统的整体吞吐量，满足这些业务，对实时性和并发性的高要求。OLTP（Online Transaction Processing，在线事务处理）OLAP（Online Analytical Processing，在线分析处理）常见的OLTP场景，比如电商，金融支付，网络游戏等场景。
2024-11-16 16:41:23
221
原创 MySQL二进制日志Binlog
MySQL的Binlog主要记录的是修改数据库数据的操作，也就是（Data Manipulation Language）操作，包括INSERTUPDATEDELETE等语句，在中CREATEALTERDROP等DDL（Data Definition Language）操作也会记录。
2024-11-16 00:31:16
287
原创 MariaDB columnstore存储引擎
这样，当执行查询时，数据库只需要读取涉及到的列，而不是整行数据。这在处理大型数据集和复杂查询时特别有效，因为它减少了I/O操作和内存使用，从而提高了查询性能。会对数据进行压缩，可以显著减少存储空间和IO操作，并且可以使用缓存技术来加速数据访问速度。可以存储更多的数据，减少读取操作，所以可以更好的处理高并发负载，从而提高整个系统的吞吐量。使用独特的向量化查询技术，将每个列中的数据打包成向量进行计算，能够利用CPU架构的优势。可以更快的扫描大量数据，并提高查询速率，因此它成为实时数据分析的理想选择。
2024-05-07 15:20:47
290
原创 TokuDB存储引擎的应用场景有哪些
搜索跟顺序访问的速度和B树差不多，但是插入和删除的速度比B树快，因为每个节点都有允许消息节点存储的缓冲区，插入、删除和更新作为消息插入到缓冲区中，缓冲区通过合并请求，让每个磁盘操作更有效率。高并发场景：TokuDB采用分形树，插入和删除速度比B树快，所以有高并发写入的场景，可以考虑使用TokuDB。要求高可靠性的场景：TokuDB提供了复制和故障转移功能，确保数据不会丢失，并且在出现故障时可以快速的恢复。数据量大的场景：TokuDB对大数据的处理能力非常强大，可以容纳数百亿条记录，并且还支持在线扩展。
2024-04-29 10:42:41
209
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人