MySQL 数据库主从复制小知识
1.主从状态查看
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 | mysql> SHOW SLAVE STATUS\G *************************** 1. row *************************** Slave_IO_State: Waiting for master to send event Master_Host: localhost Master_User: repl Master_Port: 13000 Connect_Retry: 60 Master_Log_File: master-bin.000002 Read_Master_Log_Pos: 1307 Relay_Log_File: slave-relay-bin.000003 Relay_Log_Pos: 1508 Relay_Master_Log_File: master-bin.000002 Slave_IO_Running: Yes Slave_SQL_Running: Yes Replicate_Do_DB: Replicate_Ignore_DB: Replicate_Do_Table: Replicate_Ignore_Table: Replicate_Wild_Do_Table: Replicate_Wild_Ignore_Table: Last_Errno: 0 Last_Error: Skip_Counter: 0 Exec_Master_Log_Pos: 1307 Relay_Log_Space: 1858 Until_Condition: None Until_Log_File: Until_Log_Pos: 0 Master_SSL_Allowed: No Master_SSL_CA_File: Master_SSL_CA_Path: Master_SSL_Cert: Master_SSL_Cipher: Master_SSL_Key: Seconds_Behind_Master: 0 Master_SSL_Verify_Server_Cert: No Last_IO_Errno: 0 Last_IO_Error: Last_SQL_Errno: 0 Last_SQL_Error: Replicate_Ignore_Server_Ids: Master_Server_Id: 1 Master_UUID: 3e11fa47-71ca-11e1-9e33-c80aa9429562 Master_Info_File: /var/mysqld.2/data/master.info SQL_Delay: 0 SQL_Remaining_Delay: NULL Slave_SQL_Running_State: Reading event from the relay log Master_Retry_Count: 10 Master_Bind: Last_IO_Error_Timestamp: Last_SQL_Error_Timestamp: Master_SSL_Crl: Master_SSL_Crlpath: Retrieved_Gtid_Set: 3e11fa47-71ca-11e1-9e33-c80aa9429562:1-5 Executed_Gtid_Set: 3e11fa47-71ca-11e1-9e33-c80aa9429562:1-5 Auto_Position: 1 Replicate_Rewrite_DB: Channel_name: Master_TLS_Version: TLSv1.2 |
2.主从复制相关的表
Performance Schema 中有些关于主从同步的表,这些表里的数据 和 通过 SHOW SLAVE STATUS 查看的数据部分相同。
类别 | 表名 | 表数据描述 |
connection | replication_connection_configuration |
Configuration parameters for connecting to the master. |
replication_connection_status |
Current status of the connection to the master. | |
transaction applier | replication_applier_configuration |
Configuration parameters for the transaction applier on the slave. |
replication_applier_status |
Current status of the transaction applier on the slave. | |
replication_applier_status_by_coordinator |
Status of the coordinator thread (empty unless the slave is multithreaded). | |
replication_applier_status_by_worker |
Status of the applier thread or worker threads if the slave is multithreaded. | |
group members | replication_group_members |
Provides network and status information for group members. |
replication_group_member_stats |
Provides statistical information about group members and transaction in which they participate. |
3.SHOW SLAVE STATUS Information In the Other Tables
下面这两种表在数据库MySQL中。
3.1 slave_relay_log_info 表
Line | Table Column | 约等于SHOW SLAVE STATUS Column |
Description |
1 | Number_of_lines | [None] | Number of lines in the file or columns in the table |
2 | Relay_log_name | Relay_Log_File | The name of the current relay log file |
3 | Relay_log_pos | Relay_Log_Pos | The current position within the relay log file; events up to this position have been executed on the slave database |
4 | Master_log_name | Relay_Master_Log_File | The name of the master binary log file from which the events in the relay log file were read |
5 | Master_log_pos | Exec_Master_Log_Pos | The equivalent position within the master's binary log file of events that have already been executed |
6 | Sql_delay | SQL_Delay | The number of seconds that the slave must lag the master |
7 | Number_of_workers | [None] | The number of slave worker threads for executing replication events (transactions) in parallel |
8 | Id | [None] | ID used for internal purposes; currently this is always 1 |
9 | Channel_name | Channel_name | The name of the replication channel |
注意:
(1)slave_relay_log_info 表存储的是持久化的状态,而 show slave status 输出的是内存中的状态,所以二者之间的一些指标数据可能不一致;
(2)stop slave 或者正常关闭 mysqld,都会将内存中的状态持久化到磁盘上(slave_relay_log_info表中);启动 mysqld 时会读取磁盘状态,初始化给内存状态;start slave 时也会初始化内存状态。
(3)在从库启动的时候时,读取 slave_relay_log_info 表中存储的位置,并把值传给 “show slave status” 中的 Relay_Log_File、Relay_Log_Pos,下次 “start slave” 是从这个位置开始继续回放 relay log;
(4)slave sql thread 按照 Relay_Log_Name、Relay_Log_Pos 位置进行 realy log 的回放.
3.2 slave_master_info 表
Line | Table Column | 约等于SHOW SLAVE STATUS Column |
Description |
1 | Number_of_lines | [None] | Number of lines in the file, or columns in the table |
2 | Master_log_name | Master_Log_File | The name of the master binary log currently being read from the master |
3 | Master_log_pos | Read_Master_Log_Pos | The current position within the master binary log that have been read from the master |
4 | Host | Master_Host | The host name of the master |
5 | User_name | Master_User | The user name used to connect to the master |
6 | User_password | Password (not shown by SHOW SLAVE STATUS ) |
The password used to connect to the master |
7 | Port | Master_Port | The network port used to connect to the master |
8 | Connect_retry | Connect_Retry | The period (in seconds) that the slave will wait before trying to reconnect to the master |
9 | Enabled_ssl | Master_SSL_Allowed | Indicates whether the server supports SSL connections |
10 | Ssl_ca | Master_SSL_CA_File | The file used for the Certificate Authority (CA) certificate |
11 | Ssl_capath | Master_SSL_CA_Path | The path to the Certificate Authority (CA) certificates |
12 | Ssl_cert | Master_SSL_Cert | The name of the SSL certificate file |
13 | Ssl_cipher | Master_SSL_Cipher | The list of possible ciphers used in the handshake for the SSL connection |
14 | Ssl_key | Master_SSL_Key | The name of the SSL key file |
15 | Ssl_verify_server_cert | Master_SSL_Verify_Server_Cert | Whether to verify the server certificate |
16 | Heartbeat | [None] | Interval between replication heartbeats, in seconds |
17 | Bind | Master_Bind | Which of the slave's network interfaces should be used for connecting to the master |
18 | Ignored_server_ids | Replicate_Ignore_Server_Ids | The list of server IDs to be ignored. Note that forIgnored_server_ids the list of server IDs is preceded by the total number of server IDs to ignore. |
19 | Uuid | Master_UUID | The master's unique ID |
20 | Retry_count | Master_Retry_Count | Maximum number of reconnection attempts permitted |
21 | Ssl_crl | [None] | Path to an SSL certificate revocation-list file |
22 | Ssl_crlpath | [None] | Path to a directory containing SSL certificate revocation-list files |
23 | Enabled_auto_position | Auto_position | If autopositioning is in use or not |
24 | Channel_name | Channel_name | The name of the replication channel |
25 | Tls_version | Master_TLS_Version | TLS version on master |
注意:
slave io thread 按照 Master_Log_File、Read_Master_Log_Pos 位置读取主库的 binlog,并写入到本地 relay log。
4.slave_parallel_workers 对 复制延迟的影响
MySQL 5.7版本已经支持“真正”的并行复制功能,官方称为为enhanced multi-threaded slave(简称MTS),因此复制延迟问题已经得到了极大的改进。
在MySQL 5.7中,设置参数slave_parallel_workers>0并且global.slave_parallel_type=‘LOGICAL_CLOCK’,即可支持一个schema下,slave_parallel_workers个的worker线程并发执行relay log中主库提交的事务。其核心思想:一个组提交的事务都是可以并行回放(配合binary log group commit)。slave机器的relay log中 last_committed相同的事务(sequence_num不同)可以并发执行。
注意:
(1)开启MTS功能后,推荐将参数master_info_repostitory设置为TABLE,这样性能可以有50%~80%的提升。这是因为并行复制开启后对于元master.info这个文件的更新将会大幅提升,资源的竞争也会变大。推荐将master_info_repository设置为TABLE,来减小这部分的开销。
(2)Coordinator thread on slave dispatches work across several worker threads。Each worker thread commits trx in isolation。
(3)推荐开启参数 slave_preserve_commit_order 。这是因为仅仅设置LOGICAL_CLOCK会存在问题--此时在slave上应用事务的顺序是无序的,和relay log中记录的事务顺序不一样,这样数据一致性是无法保证的,为了保证事务是按照relay log中记录的顺序来回放,就需要开启参数slave_preserve_commit_order。(The transactions that the slave applies in parallel may commit out of order, unless slave_preserve_commit_order=1
.)
(4)设置 slave_parallel_workers
后,需要重启slave 进程
Setting slave_parallel_workers has no immediate effect. The state of the variable applies on all subsequent START SLAVE statements.
(5)实践中遇到的一个例子,我们将 slave_parallel_workers 由值4调整为16,延迟的速率得到了明显的改善。(具体值要操作硬件配置和从库的应用。注意此图是Delay的速率,值越大说明延迟趋势越严重)
5.XtraBackup 恢复过程,对/mysql/data数据文件赋权的时机
应该在 XXX/innobackupex --copy-back /XXX 过程之后再进行数据文件所有者变更,变更主要命令如下:
chown -R mysql:mysql /XXXX/mysql/data/
否则mysql 服务无法正常启动,报错信息如下:
.. ERROR! The server quit without updating PID file (/XXX/mysql/data/tcvm255.pid).
ERROR! MySQL is not running, but lock file (/var/lock/subsys/mysql) exists
查看mysql log 主要信息如下:
2017-06-19T10:48:18.112683+08:00 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details). 2017-06-19T10:48:18.763038+08:00 0 [ERROR] InnoDB: The innodb_system data file 'ibdata1' must be writable 2017-06-19T10:48:18.763074+08:00 0 [ERROR] InnoDB: The innodb_system data file 'ibdata1' must be writable 2017-06-19T10:48:18.763080+08:00 0 [ERROR] InnoDB: Plugin initialization aborted with error Generic error 2017-06-19T10:48:19.364031+08:00 0 [ERROR] Plugin 'InnoDB' init function returned error. 2017-06-19T10:48:19.364063+08:00 0 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed. 2017-06-19T10:48:19.364075+08:00 0 [ERROR] Failed to initialize builtin plugins. 2017-06-19T10:48:19.364080+08:00 0 [ERROR] Aborting
6.主从复制如何设置指定的数据库
编辑从服务器上/etc/my.cnf的配置参数,通过参数(replicate-do-db)指定那个数据库可以进行复制;通过参数(replicate-ignore-db),指定那个数据库可以进行复制。
replicate-do-db: Tells the slave SQL thread to restrict replication to the specified database. replicate-ignore-db: Tells the slave SQL thread not to replicate to the specified database.
7.备份还原,启动实例报错
我们会遇到一种情况,原实例上有多个数据库,但是我们只需要备份还原一个库或部分库的情况。通过innobackupex工具备份指定库,例如 --databases="mysql XXXdb performance_schema",然后再还原,可能报错。
2019-09-24T19:47:09.084293+08:00 0 [Note] /qqweixin/mysql/bin/mysqld (mysqld 5.7.21-log) starting as process 51778 ... 2019-09-24T19:47:09.091489+08:00 0 [Note] InnoDB: PUNCH HOLE support available 2019-09-24T19:47:09.091559+08:00 0 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 2019-09-24T19:47:09.091572+08:00 0 [Note] InnoDB: Uses event mutexes 2019-09-24T19:47:09.091582+08:00 0 [Note] InnoDB: GCC builtin __sync_synchronize() is used for memory barrier 2019-09-24T19:47:09.091592+08:00 0 [Note] InnoDB: Compressed tables use zlib 1.2.3 2019-09-24T19:47:09.091601+08:00 0 [Note] InnoDB: Using Linux native AIO 2019-09-24T19:47:09.096199+08:00 0 [Note] InnoDB: Number of pools: 1 2019-09-24T19:47:09.096473+08:00 0 [Note] InnoDB: Using CPU crc32 instructions 2019-09-24T19:47:09.101033+08:00 0 [Note] InnoDB: Initializing buffer pool, total size = 220G, instances = 48, chunk size = 512M 2019-09-24T19:47:10.422726+08:00 0 [Note] InnoDB: Completed initialization of buffer pool 2019-09-24T19:47:10.650079+08:00 0 [Note] InnoDB: If the mysqld execution user is authorized, page cleaner thread priority can be changed. See the man page of setpriority(). 2019-09-24T19:47:10.660276+08:00 0 [ERROR] InnoDB: The Auto-extending innodb_system data file './ibdata1' is of a different size 21248 pages (rounded down to MB) than specified in the .cnf file: initial 65536 pages, max 0 (relevant if non-zero) pages! 2019-09-24T19:47:10.660303+08:00 0 [ERROR] InnoDB: Plugin initialization aborted with error Generic error 2019-09-24T19:47:11.260892+08:00 0 [ERROR] Plugin 'InnoDB' init function returned error. 2019-09-24T19:47:11.260934+08:00 0 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed. 2019-09-24T19:47:11.260948+08:00 0 [ERROR] Failed to initialize builtin plugins. 2019-09-24T19:47:11.260963+08:00 0 [ERROR] Aborting 2019-09-24T19:47:11.260982+08:00 0 [Note] Binlog end 2019-09-24T19:47:11.262087+08:00 0 [Note] /qqweixin/mysql/bin/mysqld: Shutdown complete
解决方案
在数据目录下,删除ibdata1、ib_buffer_pool、ib_logfile0、ib_logfile1、ib_logfile2、ibtmp1文件。
执行的命令如下:
rm -rf ib*
此时,实例可以启动,但是搭建主从时,会报错:
2019-09-25T09:50:26.973154+08:00 0 [Warning] Info table is not ready to be used. Table 'mysql.slave_master_info' cannot be opened. 2019-09-25T09:50:26.973165+08:00 0 [ERROR] Error in checking mysql.slave_master_info repository info type of TABLE. 2019-09-25T09:50:26.973171+08:00 0 [ERROR] Error creating master info: Error checking repositories. 2019-09-25T09:50:26.973175+08:00 0 [ERROR] Slave: Failed to initialize the master info structure for channel ''; its record may still be present in 'mysql.slave_master_info' table, consider deleting it. 2019-09-25T09:50:26.973182+08:00 0 [ERROR] Failed to create or recover replication info repositories. 2019-09-25T09:50:26.973186+08:00 0 [Note] Some of the channels are not created/initialized properly. Check for additional messages above. You will not be able to start replication on those channels until the issue is resolved and the server restarted.
如果数据库不是很大的话,建议考虑使用mysqldump 。
指定库备份
/weixinqq/mysql/bin/mysqldump --master-data=2 -uUID -pPWD --databases XXXdb --single-transaction -R --triggers > /backdbs/XXXdb.sql
导入还原
mysql -uUID -pPWD < /data/QQbackupDB/XXXdb.sql
-------------------------------------
上面这种情况的出现,常见错误原因是:主从mysql实例的配置文件(my.cnf)关于参数 innodb_data_file_path 的值设置的不相同,请留意。
8.通过XtraBackup 搭建主从
1.在GITD 模式下,通过XtraBackup恢复从实例,搭建主从,
1 2 3 4 5 6 | change master to master_host= 'XXX.XXX.XXX.XXX' , master_port=3306, master_user= 'user_test' , master_password= 'pwd' , master_auto_position=1; |
此时,主从搭建失败,一般会提示主键冲突,进一步分析原因是主从开始的【位点】 不对,例如,正确的同步关系应该是从330000位点开始同步,可是它可能从310000位点开始了同步。
原因分析:
GTID的主从模式替代了早期版本的利用二进制日志文件的名称和日志位置的做法,使用GITD使操作和维护都变得更加简洁和可靠.使用master_auto_position参数自动查找位点.我们想下,这个数据应该去哪儿找那?
可以推测查看的地方就是系统库mysql的表gtid_executed.到此,我们应该想到原因了,为什么使用innobbackupex备份还原的库需要手动设置gtid_purged的值了.因为它备份的是mysql的数据,且时效性不满足要求.[执行reset master 必要性]
正确的gtid_purged值应该如何取得那?备份目录中有一个文件xtrabackup_binlog_info ,该文件记录数据库备份时的二进制文件和位置信息.这是备份后数据库的位置.
解决方案:
如果备份是从主节点开始的,则
step 1:
1 | reset master; |
step 2:
1 | set global gtid_purged=’可跳过的GTID′; #####从xtrbackup_binlog_info文件中获取 |
step 3
1 2 3 4 5 6 | change master to master_host= 'XXX.XXX.XXX.XXX' , master_port=3306, master_user= 'user_test' , master_password= 'pwd' , master_auto_position=1; |
step 4
1 | start salve; |
如果备份是从从节点开始的,则 在上面的操作之前还需添加两步
添加的第一步:
stop slave;
添加的第二步
reset slave all;
后面的操作就和在主节点的备份一样了,即reset master;set global gtid_purged;change master to;start slave。
知识加油站:
gtid_purged用于记录已经被清除了的binlog事务集合,它是gtid_executed的子集。只有gtid_executed为空时才能手动设置该变量,此时会同时更新gtid_executed为和gtid_purged相同的值。gtid_executed为空意味着要么之前没有启动过基于GTID的复制,要么执行过RESET MASTER。执行RESET MASTER时同样也会把gtid_purged置空,即始终保持gtid_purged是gtid_executed的子集。
reset master的作用
1.For a server where binary logging is enabled (log_bin
is ON
), RESET MASTER
deletes all existing binary log files and resets the binary log index file, resetting the server to its state before binary logging was started. A new empty binary log file is created so that binary logging can be restarted.
2.For a server where GTIDs are in use (gtid_mode
is ON
), issuing RESET MASTER
resets the GTID execution history. The value of the gtid_purged
system variable is set to an empty string (''
), the global value (but not the session value) of the gtid_executed
system variable is set to an empty string, and themysql.gtid_executed
table is cleared.
3.If the GTID-enabled server has binary logging enabled, RESET MASTER
also resets the binary log as described above. Note that RESET MASTER
is the method to reset the GTID execution history even if the GTID-enabled server is a replica where binary logging is disabled; RESET SLAVE
has no effect on the GTID execution history.
(1)删除binlog索引文件中列出的所有binlog文件;清空binlog索引文件;创建一个新的binlog文件.(2)清空系统变量gtid_purged和gtid_executed.(3)在MySQL 5.7.5 及后续版本中, RESET MASTER还会会清空 mysql.gtid_executed 数据表。
reset slave的作用
RESET SLAVE
makes the replica forget its replication position in the source's binary log. This statement is meant to be used for a clean start: It clears the replication metadata repositories, deletes all the relay log files, and starts a new relay log file. It also resets to 0 the replication delay specified with the MASTER_DELAY
option to CHANGE MASTER TO
.
(1)清除slave 复制时的master binlog的位置;(2)清空master info, relay log info;删除所有的relay log文件,并创建一个新的relay log文件;(3)重置复制延迟(CHANGE MASTER TO 的 MASTER_DELAY参数指定的)为0。
For a server where GTIDs are in use (gtid_mode
is ON
), issuing RESET SLAVE
has no effect on the GTID execution history. The statement does not change the values of gtid_executed
or gtid_purged
, or themysql.gtid_executed
table. If you need to reset the GTID execution history, use RESET MASTER
, even if the GTID-enabled server is a replica where binary logging is disabled.
To use RESET SLAVE
, the replication threads must be stopped, so on a running replica use STOP SLAVE
before issuing RESET SLAVE
. To use RESET SLAVE
on a Group Replication group member, the member status must be OFFLINE
, meaning that the plugin is loaded but the member does not currently belong to any group. A group member can be taken offline by using a STOP GROUP REPLICATION
statement.
9.dump导入导出报错
再GTID模式下,导入时报错,信息如下
mysql: [Warning] Using a password on the command line interface can be insecure. ERROR 1840 (HY000) at line 24: @@GLOBAL.GTID_PURGED can only be set when @@GLOBAL.GTID_EXECUTED is empty.
在dump导出时,添加--set-gtid-purged=off参数,避免将gtid信息导出。
10.通过xtrabackup备份,找不到xtrabackup_binlog_info文件
通过xtrabackup备份,而在搭建主从时却找不到xtrabackup_binlog_info文件。异常原因是,没有开启 log-bin 参数
解决方案: 开启MySQL的binlog日志
在配置文件中my.cnf 添加以下参数
log-bin = mysql-bin
11. 从节点执行 reset slave all
注意:在从节点上执行reset slave all,会将本地已缓存的relay log清空,一个不剩。
12. 主从延迟过大
主从延迟过大,可在从库实例上调整以下参数,使从库快速追上主库。
set GLOBAL innodb_flush_log_at_trx_commit=0; set GLOBAL sync_binlog=500000; set GLOBAL sync_relay_log=500000;
效果图
待主从延迟解决后,建议恢复原来设置。
13.innobackupex 备份导致主从延迟
备份过程中迟迟不能提交结束的"FLUSH TABLES WITH READ LOCK"导致延迟逐渐增大,甚至此时执行stop slave都hang住。
通过show full processlist 查看 lock 如下:
*************************** 8. row *************************** Id: 645508 User: XXXXXXXX Host: localhost db: NULL Command: Query Time: 6774 State: Waiting for commit lock Info: FLUSH TABLES WITH READ LOCK
解决方案
建议先kill点备份的进程,例如本案
kill 645508
14. 创建函数报错
mysql的设置默认是不允许创建函数,执行报错
Error Code: 1418. This function has none of DETERMINISTIC, NO SQL, or READS SQL DATA in its declaration and binary logging is enabled (you *might* want to use the less safe log_bin_trust_function_creators variable)
解决方案
在my.cnf里面设置
log-bin-trust-function-creators=1
注意: 有主从复制的时候 从机必须要设置 不然会导致主从同步失败。
15 备份还原报错
1 2 3 4 5 6 | 2018-12-11T13:54:51.828032+08:00 0 [ERROR] InnoDB: <strong>Unable to open undo tablespace './/undo001' .< /strong > 2018-12-11T13:54:51.828073+08:00 0 [ERROR] InnoDB: Plugin initialization aborted with error Generic error 2018-12-11T13:54:52.328866+08:00 0 [ERROR] Plugin 'InnoDB' init function returned error. 2018-12-11T13:54:52.328925+08:00 0 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed. 2018-12-11T13:54:52.328935+08:00 0 [ERROR] Failed to initialize builtin plugins. 2018-12-11T13:54:52.328963+08:00 0 [ERROR] Aborting |
报错原因可能是两台实例的mysql配置文件不一致(my.conf)
例如:主库
cat my.cnf | grep innodb_undo_tablespaces
结果为
innodb_undo_tablespaces = 3
而从库没有设置。
16. 通过binlog中server_id变化,查找pos位点
正常情况下slave的binlog里面带入的是master的server-id,主从切换后,当slave开始写入数据时,那么自己的server-id 就会记录在binlog里面。
所以只需要在老slave(新master节点)的binlog找到 自己的 server-id开始的pos点时,就是原master(将以新slave身份加入)恢复的时候,再次搭建change master to 需要指向的pos点。
有两种实现做法:
1.自己解析binlog根据server-id寻找pos点。比如需要确认大概什么时候切换的,然后找到具体那个时间段的binlog开始解析。
2.利用python-mysql-replication这个库来找寻。
资料学习:
https://dev.mysql.com/doc/refman/5.7/en/slave-logs-status.html
https://blog.csdn.net/ActionTech/article/details/102588957
https://dev.mysql.com/doc/refman/5.7/en/replication-options-slave.html
https://dev.mysql.com/doc/refman/5.7/en/performance-schema-replication-tables.html
https://www.cnblogs.com/langdashu/p/6125621.html
https://www.cnblogs.com/xiaotengyi/p/5532191.html
https://www.cnblogs.com/softidea/p/12781094.html
https://www.cnblogs.com/zetanchen/p/10164807.html
巧用python-mysql-replication寻找pos点
http://t.zoukankan.com/gomysql-p-12867967.html
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】凌霞软件回馈社区,博客园 & 1Panel & Halo 联合会员上线
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】博客园社区专享云产品让利特惠,阿里云新客6.5折上折
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· [.NET]调用本地 Deepseek 模型
· 一个费力不讨好的项目,让我损失了近一半的绩效!
· .NET Core 托管堆内存泄露/CPU异常的常见思路
· PostgreSQL 和 SQL Server 在统计信息维护中的关键差异
· C++代码改造为UTF-8编码问题的总结
· 一个费力不讨好的项目,让我损失了近一半的绩效!
· 清华大学推出第四讲使用 DeepSeek + DeepResearch 让科研像聊天一样简单!
· 实操Deepseek接入个人知识库
· CSnakes vs Python.NET:高效嵌入与灵活互通的跨语言方案对比
· Plotly.NET 一个为 .NET 打造的强大开源交互式图表库