MySQL行级别并行复制能并行应用多少个binlog group？

于 2019-09-09 15:34:55 发布
阅读量610 收藏
点赞数
分类专栏： MySQL 文章标签： MySQL binlog
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/woqutechteam/article/details/100663737
版权
本文介绍了如何通过MySQL 5.7和8.0的性能表来观察行级别并行复制的并行数量。通过对MySQL 8.0的`performance_schema.replication_applier_status_by_worker`表中的数据进行分析，发现并行应用的binlog group可以达到3个。测试环境包括MySQL 5.7.22和8.0.17，采用sysbench进行压力测试，设置特定的复制和参数配置。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

前两天，无意间看到了林晓斌(丁奇)的一篇文章（详见文末参考链接的第一个），突发好奇心，想从MySQL暴露出来的一些信息上着手，看看能不能直观地看到MySQL 5.7的并行复制到底可以同时执行多少个binlog group(last_committed)的事务，经过一番折腾，将验证过程整理成这篇文章分享给大家。测试验证过程中，使用了两个MySQL版本，如下：

  • MySQL 5.7.22：sysbench加压，然后在从库中查询information_schema.innodb_trx、performance_schema.events_transactions_current、performance_schema.replication_applier_status_by_worker 三张表中的数据，反复操作，发现并没有可靠数据能满足要求。

  • MySQL 8.0.17：sysbench加压，然后在从库中查询performance_schema.replication_applier_status_by_worker 表，发现该表相比之前的版本新增了一个字段看起来比较可靠（这里先卖个关子，具体哪个字段，请大家从下文中寻找吧）。

No.1 环  境

数据库版本：MySQL 5.7.22、MySQL 8.0.17

  • 复制拓扑：一主两从

数据库关键参数：

  • 主库：

    binlog_transaction_dependency_tracking=COMMIT_ORDER

  • 主从库：双一、binlog_order_commits=ON、slave_preserve_commit_order=ON

  • 从库：双TABLE，slave_parallel_workers=32，slave_parallel_type=LOGICAL_CLOCK

sysbench版本：sysbench 1.0.9

  • 对主库使用32线程加oltp压力

  • 测试基础数据量：8张500W的表

操作系统版本：CentOS Linux release 7.2.1511 (Core)

文件系统：xfs

IO调度策略：deadline

PS：以下测试数据均为MySQL 8.0.17，由于MySQL 5.7.22的测试数据并不是那么可靠（本人观点），所以本文中并未列出。

No.2 预  热

MySQL行级别的并行复制，是在MySQL 5.7及其之后的版本中引入的，在MySQL 5.6中只支持库级别的并行复制，在MySQL 5.5及其更早的版本中只支持单线程复制。

关于MySQL行级别的并行复制原理，我们也许经常会听到如下说法：

  • 简单点的：从库中的协调器线程根据Gtid_log_event和Anonymous_gtid_log_event中记录的last_committed值做并行分发，相同的last_committed值的事务就可以并行应用。

  • 复杂点的：主库在做并行事务提交时，处于prepare状态的事务都可以在从库并行应用，因为他们不存在锁冲突。

    * 主库侧：在提交事务时，对每个事务定义其lock interval，并记录到binlog中。使用last_committed表示事务lock interval的起始点，它是在事务进入prepare阶段之后，进入binlog flush队列之前获取的当时commit队列（这里指的是事务提交的flush、sync、commit三个队列中的commit队列）中所有事务的最大sequence_number（为什么要从commit队列里获取，而不是从已提交完成的事务中获取呢？因为提交完成的事务锁已经释放，无法判断有没有锁冲突）；使用sequence_number表示事务lock interval的结束点，它是在事务进入binlog flush队列之后从当时正在使用的binlog file的事务计数器中获取值（每个binlog file都会将计数器重置）。

    * 从库侧：协调器线程根据last_committed做分发，只要last_committed和sequence_number组成的lock interval锁范围重叠的事务，就可以并行应用（可以分发）。具体实现上，在MySQL内部定义了一个last_lwm_timestamp变量，用来记录所有回放事务中已经提交完成事务的timestamp(sequence_number)的low-water-mark。low-water-mark对应的事务已经提交，且该事务之前的事务（seqno小于low-water-mark的事务）都已经提交。当协调器线程读取到一个事务的last_committed值时，判断该事务的last_committed值是否小于等于low-water-mark值，如果是，则协调器线程就可以将其分发给worker线程（具体是否分发还需要看是否有worker线程处于空闲状态，如果没有worker线程处于空闲，协调器线程需要等待空闲的worker线程），否则，协调器线程不能将该事务分发给worker线程，需要进行等待。

    * 从库侧并行分发策略的逻辑图解：假设下图中的L代表lock interval的开始，C代表lock interval的结束。

下面，我们一起来看看，除了撸源码总结并行复制原理之外，怎么通过MySQL暴露出来的一些信息来查看并行复制的踪迹。

No.3 揭  底

主库停止任何写压力，并确定从库无延迟。

root@localhost : (none):28: > show slave status\G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 10.10.30.162
                  Master_User: repl
                  Master_Port: 3306
                Connect_Retry: 10
              Master_Log_File: mysql-bin.000029
          Read_Master_Log_Pos: 501683714
               Relay_Log_File: mysql-relay-bin.000086
                Relay_Log_Pos: 497690559
        Relay_Master_Log_File: mysql-bin.000029
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
......
          Exec_Master_Log_Pos: 501683714
              Relay_Log_Space: 501684223
......
        Seconds_Behind_Master: 0
......

为减少后续的日志解析量，在主库与从库都各自执行binlog日志切换。

# 主库
mysql > flush binary logs;
Query OK, 0 rows affected (0.02 sec)

# 从库
mysql > flush binary logs;
Query OK, 0 rows affected (0.02 sec)

对主库sysbench加并发压力（这里为oltp事务模型）。

[root@physical-machine ~]# sysbench --db-driver=mysql --time=99999 --threads=32 --report-interval=1 --mysql-host=10.10.30.162 --mysql-port=3306 --mysql-user=qbench --mysql-password=qbench --mysql-db=sbtest --tables=2 --table-size=5000000 oltp_read_write --db-ps-mode=disable --mysql-ignore-errors=1062 run

在从库中反复执行如下语句，直到抓取到较多的数据行为止（任选其中一个从库即可）。

mysql > select THREAD_ID,SERVICE_STATE,LAST_APPLIED_TRANSACTION,APPLYING_TRANSACTION,APPLYING_TRANSACTION_START_APPLY_TIMESTAMP from performance_schema.replication_applier_status_by_worker where APPLYING_TRANSACTION!='' order by APPLYING_TRANSACTION;select * from sys.innodb_lock_waits\G
+-----------+---------------+----------------------------------------------+----------------------------------------------+--------------------------------------------+
| THREAD_ID | SERVICE_STATE | LAST_APPLIED_TRANSACTION | APPLYING_TRANSACTION | APPLYING_TRANSACTION_START_APPLY_TIMESTAMP |
+-----------+---------------+----------------------------------------------+----------------------------------------------+--------------------------------------------+
| 94 | ON | 364efb4f-c7e8-11e9-8f23-5254002a54f2:1536428 | 364efb4f-c7e8-11e9-8f23-5254002a54f2:1536438 | 2019-08-27 09:53:16.941561 |
| 95 | ON | 364efb4f-c7e8-11e9-8f23-5254002a54f2:1536429 | 364efb4f-c7e8-11e9-8f23-5254002a54f2:1536439 | 2019-08-27 09:53:16.941590 |
| 96 | ON | 364efb4f-c7e8-11e9-8f23-5254002a54f2:1536430 | 364efb4f-c7e8-11e9-8f23-5254002a54f2:1536440 | 2019-08-27 09:53:16.941654 |
| 97 | ON | 364efb4f-c7e8-11e9-8f23-5254002a54f2:1536431 | 364efb4f-c7e8-11e9-8f23-5254002a54f2:1536441 | 2019-08-27 09:53:16.942482 |
| 98 | ON | 364efb4f-c7e8-11e9-8f23-5254002a54f2:1536432 | 364efb4f-c7e8-11e9-8f23-5254002a54f2:1536442 | 2019-08-27 09:53:16.942137 |
| 99 | ON | 364efb4f-c7e8-11e9-8f23-5254002a54f2:1536433 | 364efb4f-c7e8-11e9-8f23-5254002a54f2:1536443 | 2019-08-27 09:53:16.941958 |
| 100 | ON | 364efb4f-c7e8-11e9-8f23-5254002a54f2:1536434 | 364efb4f-c7e8-11e9-8f23-5254002a54f2:1536444 | 2019-08-27 09:53:16.941935 |
| 101 | ON | 364efb4f-c7e8-11e9-8f23-5254002a54f2:1536435 | 364efb4f-c7e8-11e9-8f23-5254002a54f2:1536445 | 2019-08-27 09:53:16.945607 |
| 102 | ON | 364efb4f-c7e8-11e9-8f23-5254002a54f2:1536436 | 364efb4f-c7e8-11e9-8f23-5254002a54f2:1536446 | 2019-08-27 09:53:16.945996 |
| 103 | ON | 364efb4f-c7e8-11e9-8f23-5254002a54f2:1536423 | 364efb4f-c7e8-11e9-8f23-5254002a54f2:1536447 | 2019-08-27 09:53:16.946397 |
| 104 | ON | 364efb4f-c7e8-11e9-8f23-5254002a54f2:1536424 | 364efb4f-c7e8-11e9-8f23-5254002a54f2:1536448 | 2019-08-27 09:53:16.946338 |
| 105 | ON | 364efb4f-c7e8-11e9-8f23-5254002a54f2:1536425 | 364efb4f-c7e8-11e9-8f23-5254002a54f2:1536449 | 2019-08-27 09:53:16.946429 |
| 106 | ON | 364efb4f-c7e8-11e9-8f23-5254002a54f2:1536426 | 364efb4f-c7e8-11e9-8f23-5254002a54f2:1536450 | 2019-08-27 09:53:16.946892 |
| 107 | ON | 364efb4f-c7e8-11e9-8f23-5254002a54f2:1536396 | 364efb4f-c7e8-11e9-8f23-5254002a54f2:1536451 | 2019-08-27 09:53:16.947253 |
| 108 | ON | 364efb4f-c7e8-11e9-8f23-5254002a54f2:1536397 | 364efb4f-c7e8-11e9-8f23-5254002a54f2:1536452 | 2019-08-27 09:53:16.947248 |
| 109 | ON | 364efb4f-c7e8-11e9-8f23-5254002a54f2:1536398 | 364efb4f-c7e8-11e9-8f23-5254002a54f2:1536453 | 2019-08-27 09:53:16.947896 |
| 110 | ON | 364efb4f-c7e8-11e9-8f23-5254002a54f2:1536399 | 364efb4f-c7e8-11e9-8f23-5254002a54f2:1536454 | 2019-08-27 09:53:16.948349 |
| 111 | ON | 364efb4f-c7e8-11e9-8f23-5254002a54f2:1536400 | 364efb4f-c7e8-11e9-8f23-5254002a54f2:1536455 | 2019-08-27 09:53:16.947968 |
| 112 | ON | 364efb4f-c7e8-11e9-8f23-5254002a54f2:1536401 | 364efb4f-c7e8-11e9-8f23-5254002a54f2:1536456 | 2019-08-27 09:53:16.948032 |
| 113 | ON | 364efb4f-c7e8-11e9-8f23-5254002a54f2:1536402 | 364efb4f-c7e8-11e9-8f23-5254002a54f2:1536457 | 2019-08-27 09:53:16.948247 |
| 114 | ON | 364efb4f-c7e8-11e9-8f23-5254002a54f2:1536403 | 364efb4f-c7e8-11e9-8f23-5254002a54f2:1536458 | 2019-08-27 09:53:16.948836 |
| 115 | ON | 364efb4f-c7e8-11e9-8f23-5254002a54f2:1536404 | 364efb4f-c7e8-11e9-8f23-5254002a54f2:1536459 | 2019-08-27 09:53:16.948152 |
| 116 | ON | 364efb4f-c7e8-11e9-8f23-5254002a54f2:1536408 | 364efb4f-c7e8-11e9-8f23-5254002a54f2:1536460 | 2019-08-27 09:53:16.948203 |
| 117 | ON | 364efb4f-c7e8-11e9-8f23-5254002a54f2:1536409 | 364efb4f-c7e8-11e9-8f23-5254002a54f2:1536461 | 2019-08-27 09:53:16.948407 |
| 118 | ON | 364efb4f-c7e8-11e9-8f23-5254002a54f2:1536375 | 364efb4f-c7e8-11e9-8f23-5254002a54f2:1536462 | 2019-08-27 09:53:16.948316 |
| 119 | ON | 364efb4f-c7e8-11e9-8f23-5254002a54f2:1536376 | 364efb4f-c7e8-11e9-8f23-5254002a54f2:1536463 | 2019-08-27 09:53:16.948345 |
+-----------+---------------+----------------------------------------------+----------------------------------------------+--------------------------------------------+
26 rows in set (0.00 sec)

Empty set (0.00 sec)

上述文本中，相比MySQL 5.7.22版本，我们使用了performance_schema.replication_applier_status_by_worker表中新增的3个字段（当然新增的字段还有很多时间戳的，这里并未使用）。

  • LAST_APPLIED_TRANSACTION：此worker线程已完成应用的最后一个事务的GTID。

  • APPLYING_TRANSACTION：此worker线程当前正在应用的事务的GTID。

  • APPLYING_TRANSACTION_START_APPLY_TIMESTAMP：此worker线程第一次尝试应用当前事务的时间戳。

从上述文本中，我们可以看到一共抓取到26个事务正在并行，GTID SET为364efb4f-c7e8-11e9-8f23-5254002a54f2:1536438-1536463，使用这个GTID SET，解析主库的最后一个binlog file去瞧瞧这些事务对应的last_committed值。

  • 上述文本太长可能导致阅读不便，下面给出一张截图。

停止对主库加压的sysbench进程，并登陆到主库服务器中，解析最后一个binlog。

[root@node1 ~]# cd /data/mysqldata1/binlog/
[root@node1 binlog]# ll
total 10530608
......
-rw-r----- 1 mysql mysql 536879186 Aug 27 09:52 mysql-bin.000035
-rw-r----- 1 mysql mysql 91067601 Aug 27 09:53 mysql-bin.000036
-rw-r----- 1 mysql mysql 1092 Aug 26 10:55 mysql-bin.index
[root@node1 binlog]# mysqlbinlog mysql-bin.000036 |grep -Ei 'last_committed|gtid_next' > a.sql

在主库中打开a.sql文件，并找到在从库中获取的GTID SET对应的日志记录（364efb4f-c7e8-11e9-8f23-5254002a54f2:1536438-1536463），从中找出对应事务的last_committed值。

[root@node1 binlog]# vim a.sql
......
#190827 9:53:16 server id 33061 end_log_pos 75854707 CRC32 0x1aeb8b8e GTID last_committed=35729 sequence_number=35755 rbr_only=yes original_committed_timestamp=1566870796937319 immediate_commit_timestamp=1566870796937319 transaction_length=1103
SET @@SESSION.GTID_NEXT= '364efb4f-c7e8-11e9-8f23-5254002a54f2:1536438'/*!*/;

# 为简化内容，以下将本案例中无用的类似"rbr_only=yes original_committed_timestamp=1566870796937319 immediate_commit_timestamp=1566870796937319 transaction_length=1103"信息删除
#190827 9:53:16 server id 33061 end_log_pos 75855810 CRC32 0xd6c147e8 GTID last_committed=35729 sequence_number=35756 ......
SET @@SESSION.GTID_NEXT= '364efb4f-c7e8-11e9-8f23-5254002a54f2:1536439'/*!*/;
#190827 9:53:16 server id 33061 end_log_pos 75857586 CRC32 0xae2abece GTID last_committed=35729 sequence_number=35757 ......
SET @@SESSION.GTID_NEXT= '364efb4f-c7e8-11e9-8f23-5254002a54f2:1536440'/*!*/;
#190827 9:53:16 server id 33061 end_log_pos 75859908 CRC32 0x2c865187 GTID last_committed=35729 sequence_number=35758 ......
SET @@SESSION.GTID_NEXT= '364efb4f-c7e8-11e9-8f23-5254002a54f2:1536441'/*!*/;
#190827 9:53:16 server id 33061 end_log_pos 75861566 CRC32 0xc902562d GTID last_committed=35743 sequence_number=35759 ......
SET @@SESSION.GTID_NEXT= '364efb4f-c7e8-11e9-8f23-5254002a54f2:1536442'/*!*/;
#190827 9:53:16 server id 33061 end_log_pos 75863342 CRC32 0xd424cb7a GTID last_committed=35743 sequence_number=35760 ......
SET @@SESSION.GTID_NEXT= '364efb4f-c7e8-11e9-8f23-5254002a54f2:1536443'/*!*/;
#190827 9:53:16 server id 33061 end_log_pos 75865000 CRC32 0xd02babfd GTID last_committed=35743 sequence_number=35761 ......
SET @@SESSION.GTID_NEXT= '364efb4f-c7e8-11e9-8f23-5254002a54f2:1536444'/*!*/;
#190827 9:53:16 server id 33061 end_log_pos 75867322 CRC32 0x4238d788 GTID last_committed=35743 sequence_number=35762 ......
SET @@SESSION.GTID_NEXT= '364efb4f-c7e8-11e9-8f23-5254002a54f2:1536445'/*!*/;
#190827 9:53:16 server id 33061 end_log_pos 75868980 CRC32 0x251ff97f GTID last_committed=35743 sequence_number=35763 ......
SET @@SESSION.GTID_NEXT= '364efb4f-c7e8-11e9-8f23-5254002a54f2:1536446'/*!*/;
#190827 9:53:16 server id 33061 end_log_pos 75871302 CRC32 0xd2d680c6 GTID last_committed=35743 sequence_number=35764 ......
SET @@SESSION.GTID_NEXT= '364efb4f-c7e8-11e9-8f23-5254002a54f2:1536447'/*!*/;
#190827 9:53:16 server id 33061 end_log_pos 75873078 CRC32 0x603e6480 GTID last_committed=35743 sequence_number=35765 ......
SET @@SESSION.GTID_NEXT= '364efb4f-c7e8-11e9-8f23-5254002a54f2:1536448'/*!*/;     
#190827 9:53:16 server id 33061 end_log_pos 75875400 CRC32 0x5bc4e556 GTID last_committed=35743 sequence_number=35766 ......
SET @@SESSION.GTID_NEXT= '364efb4f-c7e8-11e9-8f23-5254002a54f2:1536449'/*!*/;    
#190827 9:53:16 server id 33061 end_log_pos 75877722 CRC32 0x0d21cd79 GTID last_committed=35753 sequence_number=35767 ......
SET @@SESSION.GTID_NEXT= '364efb4f-c7e8-11e9-8f23-5254002a54f2:1536450'/*!*/;     
#190827 9:53:16 server id 33061 end_log_pos 75879694 CRC32 0x8c8f8092 GTID last_committed=35743 sequence_number=35768 ......
SET @@SESSION.GTID_NEXT= '364efb4f-c7e8-11e9-8f23-5254002a54f2:1536451'/*!*/;    
#190827 9:53:16 server id 33061 end_log_pos 75882016 CRC32 0xb99f0971 GTID last_committed=35753 sequence_number=35769 ......
SET @@SESSION.GTID_NEXT= '364efb4f-c7e8-11e9-8f23-5254002a54f2:1536452'/*!*/;    
#190827 9:53:16 server id 33061 end_log_pos 75883674 CRC32 0x695fc9da GTID last_committed=35753 sequence_number=35770 ......
SET @@SESSION.GTID_NEXT= '364efb4f-c7e8-11e9-8f23-5254002a54f2:1536453'/*!*/;     
#190827 9:53:16 server id 33061 end_log_pos 75885996 CRC32 0x942a4ed5 GTID last_committed=35753 sequence_number=35771 ......
SET @@SESSION.GTID_NEXT= '364efb4f-c7e8-11e9-8f23-5254002a54f2:1536454'/*!*/;    
#190827 9:53:16 server id 33061 end_log_pos 75887772 CRC32 0xc63fbf2b GTID last_committed=35753 sequence_number=35772 ......
SET @@SESSION.GTID_NEXT= '364efb4f-c7e8-11e9-8f23-5254002a54f2:1536455'/*!*/;
#190827 9:53:16 server id 33061 end_log_pos 75889548 CRC32 0x685ba5c3 GTID last_committed=35753 sequence_number=35773 ......
SET @@SESSION.GTID_NEXT= '364efb4f-c7e8-11e9-8f23-5254002a54f2:1536456'/*!*/;   
#190827 9:53:16 server id 33061 end_log_pos 75891870 CRC32 0xf1a9cd88 GTID last_committed=35753 sequence_number=35774 ......
SET @@SESSION.GTID_NEXT= '364efb4f-c7e8-11e9-8f23-5254002a54f2:1536457'/*!*/;       
#190827 9:53:16 server id 33061 end_log_pos 75894192 CRC32 0xaf9c1dc5 GTID last_committed=35753 sequence_number=35775 ......
SET @@SESSION.GTID_NEXT= '364efb4f-c7e8-11e9-8f23-5254002a54f2:1536458'/*!*/;     
#190827 9:53:16 server id 33061 end_log_pos 75896164 CRC32 0x5bd7a2b8 GTID last_committed=35753 sequence_number=35776 ......
SET @@SESSION.GTID_NEXT= '364efb4f-c7e8-11e9-8f23-5254002a54f2:1536459'/*!*/;    
#190827 9:53:16 server id 33061 end_log_pos 75898486 CRC32 0x296ace5e GTID last_committed=35753 sequence_number=35777 ......
SET @@SESSION.GTID_NEXT= '364efb4f-c7e8-11e9-8f23-5254002a54f2:1536460'/*!*/; 
#190827 9:53:16 server id 33061 end_log_pos 75900808 CRC32 0xe8917bed GTID last_committed=35753 sequence_number=35778 ......
SET @@SESSION.GTID_NEXT= '364efb4f-c7e8-11e9-8f23-5254002a54f2:1536461'/*!*/; 
#190827 9:53:16 server id 33061 end_log_pos 75902584 CRC32 0x8b8c5080 GTID last_committed=35753 sequence_number=35779 ......
SET @@SESSION.GTID_NEXT= '364efb4f-c7e8-11e9-8f23-5254002a54f2:1536462'/*!*/;
#190827 9:53:16 server id 33061 end_log_pos 75904906 CRC32 0x4e1c0187 GTID last_committed=35753 sequence_number=35780 ......
SET @@SESSION.GTID_NEXT= '364efb4f-c7e8-11e9-8f23-5254002a54f2:1536463'/*!*/; 

上述文本太长可能导致阅读不便，下面给出两张截图（留意图中的红色方框标记处）。

从上述内容中，我们可以发现，在从库中获取到的并行应用事务的GTID SET，对应了3个last_committed值，分别为last_committed=35729、last_committed=35743、last_committed=35753。至此，验证过程结束（注意：这里的验证结果只能说明并行应用的binlog group可以达到3个，并不是说一定是3个）。

以后，与别人谈论MySQL 5.7及其之后版本的并行复制原理的时候，可别告诉他只有相同的last_committed值的事务才允许并行执行，只告诉他是根据last_committed进行分发的就够了。

PS：最后，感谢重庆八怪对本文提供支持（关于多线程复制原理的简要源码解读，可参考文末第4个链接）。

参考链接：

https://zhuanlan.zhihu.com/p/49548095

https://dev.mysql.com/doc/refman/8.0/en/replication-applier-status-by-coordinator-table.html

https://dev.mysql.com/doc/refman/8.0/en/replication-applier-status-by-worker-table.html

https://www.jianshu.com/p/8706d7422d89

http://mysql.taobao.org/monthly/2017/12/03/

| 作者简介

罗小波·沃趣科技高级数据库技术专家

IT从业多年，主要负责MySQL 产品的数据库支撑与售后二线支撑。曾参与版本发布系统、轻量级监控系统、运维管理平台、数据库管理平台的设计与编写，熟悉MySQL体系结构，Innodb存储引擎，喜好专研开源技术，多次在公开场合做过线下线上数据库专题分享，发表过多篇数据库相关的研究文章。

博客
技术干货 | cilium 原理之sock_connect
08-10 777
在集群网络使用cilium之后，最明显的情况就是：服务暴露vip+port,在集群内怎么测试都正常，但集群外访问可能是有问题的。而这就在于cilium使用的ebpf科技。
博客
干货好文 | 两地三中心到异地双活演变及关键技术探讨
04-28 1224
两地三中心和异地多活都是分布式系统的关键技术，用于保证系统的高可用性和容错性。其中最关键的技术无疑是数据同步、同步防环和数据冲突解决。
博客
ChatGPT，音乐，与数据库
04-19 3197
小编君是个不务正业，喜欢搞跨界，干啥啥不成的DBA，大概在十一年前就有个不成熟的妄念，能否用计算机来写音乐？
博客
容器化，让数据库如虎添翼
04-06 644
在如今这种信息泛滥的年代，好像否定一种事物，比接纳他更容易引起共鸣，小编君也在自问：为什么数据库容器化容易被否定？是他本身的逻辑导致的吗？做为一名数据库从业者，小编君举双手支持数据库容器化！
博客
【沃趣科技】初探MySQL迁移到ClickHouse
10-28 1022
MySQL to Clickhouse，目前有ClickHouse原生提供的同步工具、命令行同步工具和界面指引型同步工具。原生的工具暂时不能用在生产环境，命令行工具使用起来比较繁琐，界面型相对简单易用。
博客
【沃趣科技】漫游Linux块IO
09-27 590
在计算机的世界里，我们可以将业务进行抽象简化为两种场景——计算密集型和IO密集型。这两种场景下的表现，决定这一个计算机系统的能力。数据库作为一个典型的基础软件，它的所有业务逻辑同样可以抽象为这两种场景的混合。因此，一个数据库系统性能的强悍与否，往往跟操作系统和硬件提供的计算能力、IO能力紧密相关。
博客
【沃趣科技】从 Oracle 日志解析学习数据库内核原理
05-30 784
由浅入深，介绍了数据库中常见而又关键的概念，了解数据库思路以及工程实现中需要注意的事项。
博客
对信用卡欺诈 Say No｜百行代码实现简化版实时欺诈检测
03-02 4756
利用 Flink+QDecoder 可以很容易将 oracle 的增量变化取出来，同步给大数据平台或者数据湖，有助于将静态数据流动起来，帮助企业盘活数据资产，提升运营决策效果。
博客
【沃趣科技】MySQL高可用工具Orchestrator系列五：raft多节点模式安装
12-27 1113
沃趣科技作为国内领先的数据库云平台解决方案提供商，一直致力于企业级数据库云平台产品的研发，为用户提供高性能、高可用、可扩展的的数据库云环境及不同业务场景需求的数据库平台，满足客户对极致性能、数据安全、容灾备份、业务永续等需求。沃趣科技凭借专业的团队，优质的产品，前沿的技术，贴心的服务赢得了客户的信任与尊重，也获得了市场的认同。前 言本篇文章介绍Orchestrator raft多节点模式...
博客
【沃趣科技】再述mysqldump时域问题
12-25 555
沃趣科技作为国内领先的数据库云平台解决方案提供商，一直致力于企业级数据库云平台产品的研发，为用户提供高性能、高可用、可扩展的的数据库云环境及不同业务场景需求的数据库平台，满足客户对极致性能、数据安全、容灾备份、业务永续等需求。沃趣科技凭借专业的团队，优质的产品，前沿的技术，贴心的服务赢得了客户的信任与尊重，也获得了市场的认同。之前文章（引用沃趣技术--《当心！使用mysqldump备份可能会让...
博客
【沃趣科技】直方图系列1
12-23 453
沃趣科技作为国内领先的数据库云平台解决方案提供商，一直致力于企业级数据库云平台产品的研发，为用户提供高性能、高可用、可扩展的的数据库云环境及不同业务场景需求的数据库平台，满足客户对极致性能、数据安全、容灾备份、业务永续等需求。沃趣科技凭借专业的团队，优质的产品，前沿的技术，贴心的服务赢得了客户的信任与尊重，也获得了市场的认同。在这个关于直方图的简短系列中，我们将讨论为什么需要直方图以及Orac...
博客
【沃趣科技】执行计划-6：推入子查询
12-11 411
沃趣科技作为国内领先的数据库云平台解决方案提供商，一直致力于企业级数据库云平台产品的研发，为用户提供高性能、高可用、可扩展的的数据库云环境及不同业务场景需求的数据库平台，满足客户对极致性能、数据安全、容灾备份、业务永续等需求。沃趣科技凭借专业的团队，优质的产品，前沿的技术，贴心的服务赢得了客户的信任与尊重，也获得了市场的认同。在这个系列的第5部分，我们看了一些需要额外注意的”第一个子操作先执行...
博客
【沃趣科技】MySQL高可用工具Orchestrator系列四：拓扑恢复
11-27 951
沃趣科技作为国内领先的数据库云平台解决方案提供商，一直致力于企业级数据库云平台产品的研发，为用户提供高性能、高可用、可扩展的的数据库云环境及不同业务场景需求的数据库平台，满足客户对极致性能、数据安全、容灾备份、业务永续等需求。沃趣科技凭借专业的团队，优质的产品，前沿的技术，贴心的服务赢得了客户的信任与尊重，也获得了市场的认同。前言上篇文章讲了orchestrator的探测机制。本篇文章翻译...
博客
【沃趣科技】MySQL高可用工具Orchestrator系列三：探测机制
11-20 910
沃趣科技作为国内领先的数据库云平台解决方案提供商，一直致力于企业级数据库云平台产品的研发，为用户提供高性能、高可用、可扩展的的数据库云环境及不同业务场景需求的数据库平台，满足客户对极致性能、数据安全、容灾备份、业务永续等需求。沃趣科技凭借专业的团队，优质的产品，前沿的技术，贴心的服务赢得了客户的信任与尊重，也获得了市场的认同。上篇文章讲了orchestrator复制拓扑的发现方式。本篇文章我们...
博客
【沃趣科技】执行计划-5：第一个子操作的变化
11-19 299
沃趣科技作为国内领先的数据库云平台解决方案提供商，一直致力于企业级数据库云平台产品的研发，为用户提供高性能、高可用、可扩展的的数据库云环境及不同业务场景需求的数据库平台，满足客户对极致性能、数据安全、容灾备份、业务永续等需求。沃趣科技凭借专业的团队，优质的产品，前沿的技术，贴心的服务赢得了客户的信任与尊重，也获得了市场的认同。我提出了“子操作按先后顺序执行，递归向下”的解释执行计划的基本策略，...
博客
【沃趣科技】日志信息记录表|全方位认识 mysql 系统库
11-19 443
沃趣科技作为国内领先的数据库云平台解决方案提供商，一直致力于企业级数据库云平台产品的研发，为用户提供高性能、高可用、可扩展的的数据库云环境及不同业务场景需求的数据库平台，满足客户对极致性能、数据安全、容灾备份、业务永续等需求。沃趣科技凭借专业的团队，优质的产品，前沿的技术，贴心的服务赢得了客户的信任与尊重，也获得了市场的认同。在上一期《复制信息记录表|全方位认识 mysql 系统库》中，我们详...
博客
【沃趣科技】MySQL高可用工具Orchestrator系列二：复制拓扑的发现
11-12 878
沃趣科技作为国内领先的数据库云平台解决方案提供商，一直致力于企业级数据库云平台产品的研发，为用户提供高性能、高可用、可扩展的的数据库云环境及不同业务场景需求的数据库平台，满足客户对极致性能、数据安全、容灾备份、业务永续等需求。沃趣科技凭借专业的团队，优质的产品，前沿的技术，贴心的服务赢得了客户的信任与尊重，也获得了市场的认同。背 景上篇文章讲了orchestrator单节点的安装。本篇...
博客
【沃趣科技】执行计划-4：谓词的选择时机与使用细节
11-06 358
沃趣科技作为国内领先的数据库云平台解决方案提供商，一直致力于企业级数据库云平台产品的研发，为用户提供高性能、高可用、可扩展的的数据库云环境及不同业务场景需求的数据库平台，满足客户对极致性能、数据安全、容灾备份、业务永续等需求。沃趣科技凭借专业的团队，优质的产品，前沿的技术，贴心的服务赢得了客户的信任与尊重，也获得了市场的认同。在第3部分（引用沃趣科技——执行计划-3：解释规则），我们用一个简单...
博客
【沃趣科技】prometheus配置MySQL邮件报警
11-04 1094
沃趣科技作为国内领先的数据库云平台解决方案提供商，一直致力于企业级数据库云平台产品的研发，为用户提供高性能、高可用、可扩展的的数据库云环境及不同业务场景需求的数据库平台，满足客户对极致性能、数据安全、容灾备份、业务永续等需求。沃趣科技凭借专业的团队，优质的产品，前沿的技术，贴心的服务赢得了客户的信任与尊重，也获得了市场的认同。前两期文章（引用沃趣技术——《prometheus监控多个MySQL...
博客
【沃趣科技】Oracle RAC Cache Fusion系列十八：Oracle RAC Statisticsand Wait Events
11-01 520
沃趣科技作为国内领先的数据库云平台解决方案提供商，一直致力于企业级数据库云平台产品的研发，为用户提供高性能、高可用、可扩展的的数据库云环境及不同业务场景需求的数据库平台，满足客户对极致性能、数据安全、容灾备份、业务永续等需求。沃趣科技凭借专业的团队，优质的产品，前沿的技术，贴心的服务赢得了客户的信任与尊重，也获得了市场的认同。OracleDatabasePerformanceTuning...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值