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_idsthe 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_DELAYoption 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 SLAVEbefore 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

 

posted @   东山絮柳仔  阅读(844)  评论(0编辑  收藏  举报
编辑推荐:
· [.NET]调用本地 Deepseek 模型
· 一个费力不讨好的项目,让我损失了近一半的绩效!
· .NET Core 托管堆内存泄露/CPU异常的常见思路
· PostgreSQL 和 SQL Server 在统计信息维护中的关键差异
· C++代码改造为UTF-8编码问题的总结
阅读排行:
· 一个费力不讨好的项目,让我损失了近一半的绩效!
· 清华大学推出第四讲使用 DeepSeek + DeepResearch 让科研像聊天一样简单!
· 实操Deepseek接入个人知识库
· CSnakes vs Python.NET:高效嵌入与灵活互通的跨语言方案对比
· Plotly.NET 一个为 .NET 打造的强大开源交互式图表库
点击右上角即可分享
微信分享提示