Mysql主从复制之skip-slave-start，slave-parallel-type，slave-parallel-workers参数详解和测试

已于 2023-09-12 15:05:58 修改
阅读量1.1k 收藏 1
点赞数 1
文章标签： adb
于 2023-09-12 11:28:49 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/liys0811/article/details/132827438
版权

参数1）skip-slave-start = 0  
参数详解：禁用skip-slave-start，slave进程会随着mysql启动而启动。skip-slave-start=1为开启
测试：当前slave的查不到该参数，且/etc/my.cnf也没有配置该文件，重启服务后，发现slave进程自动启动，且停服务期间master插入的数据也复制过来了，看了这个参数默认是skip-slave-start = 0 
[root@localhost:mytest1]>show global variables like '%slave-start%';
Empty set (0.01 sec)
[mysql@t3-dtpoc-dtpoc-web05 bin]$ service mysql stop
Shutting down MySQL.. SUCCESS! 
[mysql@t3-dtpoc-dtpoc-web05 bin]$ service mysql start
Starting MySQL. SUCCESS! 
[root@localhost:mytest1]>show slave status\G;
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
            
[root@localhost:mytest1]>select * from t1;
+------+------+
| id   | name |
+------+------+
| 8888 | tsss |
| 9999 | jjjj |
+------+------+
2 rows in set (0.00 sec)


我们在/etc/my.cnf写入这个参数skip-slave-start=1，然后重启服务，发现slave进程没有自动启动，停服务期间master端插入的数据也没有复制过来，说明参数生效了，看起来这个参数好像没有什么用，因为我们总是希望备机重启时自动启动slave。但是如果因为主库一个没有主键的大表整表update或者delete，从库追平日志需要一个月时间，这个时候停掉slave没有任何反应，因为slave会把当前事务复制完才会停下来，类似于CDC的停复制停不下来需要强制停掉。这个时候重启数据库服务也无法停止，只能Kill -9 杀掉mysql进程，重启服务后发现slave又从头开始复制了，这个时候你怎么办？可以skip-slave-start=1，让slave不自动启动

[root@localhost:mytest1]>show slave status\G;

             Slave_IO_Running: No
            Slave_SQL_Running: No
            
[root@localhost:mytest1]>select * from t1;
+------+------+
| id   | name |
+------+------+
| 8888 | tsss |
| 9999 | jjjj |
+------+------+
2 rows in set (0.00 sec)


参数2）slave-parallel-type = LOGICAL_CLOCK  
       slave-parallel-workers = 16 
参数详解：mysql在5.7中加入了slave_parallel_type，默认值是database，需要改成基于时钟逻辑的LOGICAL_CLOCK。slave_parallel_workers数，默认为0，按需修改，可以根据服务器的配置来开启相应的并行度。将slave_parallel_type设置为'LOGICAL_CLOCK'，slave_parallel_workers设置为大于0的值，即算是开启了并行复制

当前使用的是默认值：
[root@localhost:mytest1]>show variables like '%slave_parallel%';
+------------------------+----------+
| Variable_name          | Value    |
+------------------------+----------+
| slave_parallel_type    | DATABASE |
| slave_parallel_workers | 0        |
+------------------------+----------+
2 rows in set (0.00 sec)


我们在/etc/my.cnf写入这个参数slave-parallel-type = LOGICAL_CLOCK，slave-parallel-workers = 16然后重启服务,发现已经有16个复制线程了
注意将这个database修改为logical_clock，在此之前，需要先关闭sql_thread
stop slave sql_thread;
set global slave_parallel_type='LOGICAL_CLOCK';
start slave sql_thread;


select * from performance_schema.replication_applier_status_by_worker;
[root@localhost:mytest1]>select * from performance_schema.replication_applier_status_by_worker;
+--------------+-----------+-----------+---------------+-----------------------+-------------------+--------------------+----------------------+
| CHANNEL_NAME | WORKER_ID | THREAD_ID | SERVICE_STATE | LAST_SEEN_TRANSACTION | LAST_ERROR_NUMBER | LAST_ERROR_MESSAGE | LAST_ERROR_TIMESTAMP |
+--------------+-----------+-----------+---------------+-----------------------+-------------------+--------------------+----------------------+
|              |         1 |        27 | ON            | ANONYMOUS             |                 0 |                    | 0000-00-00 00:00:00  |
|              |         2 |        28 | ON            |                       |                 0 |                    | 0000-00-00 00:00:00  |
|              |         3 |        29 | ON            |                       |                 0 |                    | 0000-00-00 00:00:00  |
|              |         4 |        30 | ON            |                       |                 0 |                    | 0000-00-00 00:00:00  |
|              |         5 |        31 | ON            |                       |                 0 |                    | 0000-00-00 00:00:00  |
|              |         6 |        32 | ON            |                       |                 0 |                    | 0000-00-00 00:00:00  |
|              |         7 |        33 | ON            |                       |                 0 |                    | 0000-00-00 00:00:00  |
|              |         8 |        34 | ON            |                       |                 0 |                    | 0000-00-00 00:00:00  |
|              |         9 |        35 | ON            |                       |                 0 |                    | 0000-00-00 00:00:00  |
|              |        10 |        36 | ON            |                       |                 0 |                    | 0000-00-00 00:00:00  |
|              |        11 |        39 | ON            |                       |                 0 |                    | 0000-00-00 00:00:00  |
|              |        12 |        40 | ON            |                       |                 0 |                    | 0000-00-00 00:00:00  |
|              |        13 |        41 | ON            |                       |                 0 |                    | 0000-00-00 00:00:00  |
|              |        14 |        42 | ON            |                       |                 0 |                    | 0000-00-00 00:00:00  |
|              |        15 |        43 | ON            |                       |                 0 |                    | 0000-00-00 00:00:00  |
|              |        16 |        44 | ON            |                       |                 0 |                    | 0000-00-00 00:00:00  |
+--------------+-----------+-----------+---------------+-----------------------+-------------------+--------------------+----------------------+
16 rows in set (0.00 sec)

我们来测试下，对于没有主键的单表的全表更新有没有性能提升？我们之前做过测试对于Log_test的更新，可以看到5分钟的时间，从库更新了不到10000行数据（28300-8962=19338行）。
而开启并发以后发现5分钟的时间，从库更新了31228-14650=16578行，性能并没有提升。可以分析是因为对于一个事务只能有一个线程执行，所有并没有触发并发
[root@localhost:mytest1]>set transaction_isolation='READ-UNCOMMITTED';
Query OK, 0 rows affected (0.00 sec)
[root@localhost:mytest1]>select now();
+---------------------+
| now()               |
+---------------------+
| 2023-09-12 10:34:24 |
+---------------------+
1 row in set (0.00 sec)

[root@localhost:mytest1]>select count(*) from log_test where id>80000000;
+----------+
| count(*) |
+----------+
|    14650 |
+----------+
1 row in set (2.18 sec)
[root@localhost:mytest1]>select now();
+---------------------+
| now()               |
+---------------------+
| 2023-09-12 10:39:24 |
+---------------------+
1 row in set (0.00 sec)

[root@localhost:mytest1]>select count(*) from log_test where id>80000000;
+----------+
| count(*) |
+----------+
|    31228 |
+----------+
1 row in set (3.04 sec)

我们来测试下，对于没有主键的两个表的全表更新，从库会不会两张表并发复制？复制效率怎么样？
主端插入log_test400W行数据，然后创建表log_test1，再插入log_test1 400W行，发现从库只有把log_test400W行数据全复制完后才会创建log_test1然后再插入，说明并发复制并不会并发事务

[root@localhost:mytest1]>select count(*) from log_test1;
ERROR 1146 (42S02): Table 'mytest1.log_test1' doesn't exist
[root@localhost:mytest1]>select count(*) from log_test;
+----------+
| count(*) |
+----------+
|  8000000 |
+----------+
1 row in set (5.26 sec)

[root@localhost:mytest1]>select count(*) from log_test1;
+----------+
| count(*) |
+----------+
|   299012 |
+----------+
1 row in set (0.13 sec)

再次确认并发是打开的，主库更新两张表后，从库一直在更新一张表，说明事务并没有并发，这和预期不符啊，这算什么并发啊。

[root@localhost:mytest1]>select * from performance_schema.replication_applier_status_by_worker;
+--------------+-----------+-----------+---------------+-----------------------+-------------------+--------------------+----------------------+
| CHANNEL_NAME | WORKER_ID | THREAD_ID | SERVICE_STATE | LAST_SEEN_TRANSACTION | LAST_ERROR_NUMBER | LAST_ERROR_MESSAGE | LAST_ERROR_TIMESTAMP |
+--------------+-----------+-----------+---------------+-----------------------+-------------------+--------------------+----------------------+
|              |         1 |        31 | ON            | ANONYMOUS             |                 0 |                    | 0000-00-00 00:00:00  |
|              |         2 |        32 | ON            |                       |                 0 |                    | 0000-00-00 00:00:00  |
|              |         3 |        33 | ON            |                       |                 0 |                    | 0000-00-00 00:00:00  |
|              |         4 |        34 | ON            |                       |                 0 |                    | 0000-00-00 00:00:00  |
|              |         5 |        35 | ON            |                       |                 0 |                    | 0000-00-00 00:00:00  |
|              |         6 |        36 | ON            |                       |                 0 |                    | 0000-00-00 00:00:00  |
|              |         7 |        37 | ON            |                       |                 0 |                    | 0000-00-00 00:00:00  |
|              |         8 |        38 | ON            |                       |                 0 |                    | 0000-00-00 00:00:00  |
|              |         9 |        39 | ON            |                       |                 0 |                    | 0000-00-00 00:00:00  |
|              |        10 |        40 | ON            |                       |                 0 |                    | 0000-00-00 00:00:00  |
|              |        11 |        41 | ON            |                       |                 0 |                    | 0000-00-00 00:00:00  |
|              |        12 |        42 | ON            |                       |                 0 |                    | 0000-00-00 00:00:00  |
|              |        13 |        43 | ON            |                       |                 0 |                    | 0000-00-00 00:00:00  |
|              |        14 |        44 | ON            |                       |                 0 |                    | 0000-00-00 00:00:00  |
|              |        15 |        45 | ON            |                       |                 0 |                    | 0000-00-00 00:00:00  |
|              |        16 |        46 | ON            |                       |                 0 |                    | 0000-00-00 00:00:00  |
+--------------+-----------+-----------+---------------+-----------------------+-------------------+--------------------+----------------------+
16 rows in set (0.00 sec)

[root@localhost:mytest1]>select count(*) from log_test where id>80000000; 
+----------+
| count(*) |
+----------+
|    20970 |
+----------+
1 row in set (4.55 sec)

[root@localhost:mytest1]>select count(*) from log_test1 where id>80000000;
+----------+
| count(*) |
+----------+
|        0 |
+----------+
1 row in set (2.29 sec)

我们注意到只有第一个线程的LAST_ERROR_NUMBER不为空是ANONYMOUS，有可能是gtid_mode是OFF导致不能并发，接下来继续测试

[root@localhost:mytest1]>show variables like '%gtid_mode%';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| gtid_mode     | OFF   |
+---------------+-------+
1 row in set (0.00 sec)

在主库和从库的/etc/my.cnf都写入GTID的设置，然后重启服务，测试无主键的单表全表更新发现还是单线程在复制该事务，5分钟的时间，从库更新了28767-5280=23487行
#GTID相关
enforce_gtid_consistency = 1
gtid_mode = on

[root@localhost:mytest1]>show variables like '%gtid_mode%';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| gtid_mode     | ON    |
+---------------+-------+
1 row in set (0.01 sec)

[root@localhost:mytest1]>select now();
+---------------------+
| now()               |
+---------------------+
| 2023-09-12 14:07:39 |
+---------------------+
1 row in set (0.00 sec)

[root@localhost:mytest1]>select count(*) from log_test where id>80000000;
+----------+
| count(*) |
+----------+
|     5280 |
+----------+
1 row in set (2.44 sec)


[root@localhost:mytest1]>select now();
+---------------------+
| now()               |
+---------------------+
| 2023-09-12 14:12:39 |
+---------------------+
1 row in set (0.00 sec)

[root@localhost:mytest1]>select count(*) from log_test where id>80000000;
+----------+
| count(*) |
+----------+
|    28767 |
+----------+
1 row in set (2.30 sec)
[root@localhost:mytest1]>select * from performance_schema.replication_applier_status_by_worker;
+--------------+-----------+-----------+---------------+----------------------------------------+-------------------+--------------------+----------------------+
| CHANNEL_NAME | WORKER_ID | THREAD_ID | SERVICE_STATE | LAST_SEEN_TRANSACTION                  | LAST_ERROR_NUMBER | LAST_ERROR_MESSAGE | LAST_ERROR_TIMESTAMP |
+--------------+-----------+-----------+---------------+----------------------------------------+-------------------+--------------------+----------------------+
|              |         1 |        32 | ON            | 6797f03c-2122-11ee-842b-00505695c6d5:8 |                 0 |                    | 0000-00-00 00:00:00  |
|              |         2 |        33 | ON            |                                        |                 0 |                    | 0000-00-00 00:00:00  |
|              |         3 |        34 | ON            |                                        |                 0 |                    | 0000-00-00 00:00:00  |
|              |         4 |        35 | ON            |                                        |                 0 |                    | 0000-00-00 00:00:00  |
|              |         5 |        36 | ON            |                                        |                 0 |                    | 0000-00-00 00:00:00  |
|              |         6 |        37 | ON            |                                        |                 0 |                    | 0000-00-00 00:00:00  |
|              |         7 |        38 | ON            |                                        |                 0 |                    | 0000-00-00 00:00:00  |
|              |         8 |        39 | ON            |                                        |                 0 |                    | 0000-00-00 00:00:00  |
|              |         9 |        40 | ON            |                                        |                 0 |                    | 0000-00-00 00:00:00  |
|              |        10 |        41 | ON            |                                        |                 0 |                    | 0000-00-00 00:00:00  |
|              |        11 |        42 | ON            |                                        |                 0 |                    | 0000-00-00 00:00:00  |
|              |        12 |        43 | ON            |                                        |                 0 |                    | 0000-00-00 00:00:00  |
|              |        13 |        44 | ON            |                                        |                 0 |                    | 0000-00-00 00:00:00  |
|              |        14 |        45 | ON            |                                        |                 0 |                    | 0000-00-00 00:00:00  |
|              |        15 |        46 | ON            |                                        |                 0 |                    | 0000-00-00 00:00:00  |
|              |        16 |        47 | ON            |                                        |                 0 |                    | 0000-00-00 00:00:00  |
+--------------+-----------+-----------+---------------+----------------------------------------+-------------------+--------------------+----------------------+
16 rows in set (0.00 sec)


我们来测试下，对于没有主键的两个表的全表更新，发现还是单线程在工作，执行完插入log_test的事务才开始执行插入Log_test1的事务，并没有并发。
[root@localhost:mytest1]>select * from performance_schema.replication_applier_status_by_worker;
+--------------+-----------+-----------+---------------+-----------------------------------------+-------------------+--------------------+----------------------+
| CHANNEL_NAME | WORKER_ID | THREAD_ID | SERVICE_STATE | LAST_SEEN_TRANSACTION                   | LAST_ERROR_NUMBER | LAST_ERROR_MESSAGE | LAST_ERROR_TIMESTAMP |
+--------------+-----------+-----------+---------------+-----------------------------------------+-------------------+--------------------+----------------------+
|              |         1 |        32 | ON            | 6797f03c-2122-11ee-842b-00505695c6d5:11 |                 0 |                    | 0000-00-00 00:00:00  |
|              |         2 |        33 | ON            |                                         |                 0 |                    | 0000-00-00 00:00:00  |
|              |         3 |        34 | ON            |                                         |                 0 |                    | 0000-00-00 00:00:00  |
|              |         4 |        35 | ON            |                                         |                 0 |                    | 0000-00-00 00:00:00  |
|              |         5 |        36 | ON            |                                         |                 0 |                    | 0000-00-00 00:00:00  |
|              |         6 |        37 | ON            |                                         |                 0 |                    | 0000-00-00 00:00:00  |
|              |         7 |        38 | ON            |                                         |                 0 |                    | 0000-00-00 00:00:00  |
|              |         8 |        39 | ON            |                                         |                 0 |                    | 0000-00-00 00:00:00  |
|              |         9 |        40 | ON            |                                         |                 0 |                    | 0000-00-00 00:00:00  |
|              |        10 |        41 | ON            |                                         |                 0 |                    | 0000-00-00 00:00:00  |
|              |        11 |        42 | ON            |                                         |                 0 |                    | 0000-00-00 00:00:00  |
|              |        12 |        43 | ON            |                                         |                 0 |                    | 0000-00-00 00:00:00  |
|              |        13 |        44 | ON            |                                         |                 0 |                    | 0000-00-00 00:00:00  |
|              |        14 |        45 | ON            |                                         |                 0 |                    | 0000-00-00 00:00:00  |
|              |        15 |        46 | ON            |                                         |                 0 |                    | 0000-00-00 00:00:00  |
|              |        16 |        47 | ON            |                                         |                 0 |                    | 0000-00-00 00:00:00  |
+--------------+-----------+-----------+---------------+-----------------------------------------+-------------------+--------------------+----------------------+
16 rows in set (0.00 sec)

[root@localhost:mytest1]>select count(*) from log_test;
+----------+
| count(*) |
+----------+
|   872638 |
+----------+
1 row in set (0.47 sec)

[root@localhost:mytest1]>select count(*) from log_test1;
+----------+
| count(*) |
+----------+
|        0 |
+----------+
1 row in set (0.00 sec)

李大川的博客
关注
  • 1
    点赞
  • 踩
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
mysql同步问题之Slave延迟很大优化方法
01-19
一般而言，slave相对master延迟较大，其根本原因就是slave上的复制线程没办法真正做到并发。简单说，在master上是并发模式(以InnoDB引擎为主)完成事务提交的，而在slave上，复制线程只有一个sql thread用于binlog的apply，所以难怪slave在高并发时会远落后master。    ORACLE MySQL 5.6版本开始支持多线程复制，配置选项 slave_parallel_workers 即可实现在slave上多线程并发复制。不过，它只能支持一个实例下多个 database 间的并发复制，并不能真正做到多表并发复制。因此在较大并发负载时，slave还是没
Mysql主备-备库并行复制能力
qq_35519587的博客
06-03 335
如果备库执行日志的速度持续低于主库生成日志的速度，那这个延迟就有可能成了小时级别。而且对于一个压力持续比较高的主库来说，备库很可能永远都追不上主库的节奏。 主备流程 图中黑色的两个箭头。一个箭头代表了客户端写入主库，另一箭头代表的是备库上sql_thread执行中转日志（relay log） 日志在备库上的执行，就是图中备库上sql_thread更新数据(DATA)的逻辑。如果是用单线程的话，就会导致备库应用日志不够快，造成主备延迟。 在官方的5.6版本之前，MySQL只支持单线程复制，由此在主库并发高、
I2C-Parallel.rar_单片机开发_C++_Builder_
08-11
I2C parallel interface with slave and master combination
解决MySQL中的Slave延迟问题的基本教程
12-15
一、原因分析 一般而言，slave相对master延迟较大，其根本原因就是slave上的复制线程没办法真正做到并发。简单说，在master上是并发模式(以InnoDB引擎为主)完成事务提交的，而在slave上，复制线程只有一个sql thread用于binlog的apply，所以难怪slave在高并发时会远落后master。 ORACLE MySQL 5.6版本开始支持多线程复制，配置选项 slave_parallel_workers 即可实现在slave上多线程并发复制。不过，它只能支持一个实例下多个 database 间的并发复制，并不能真正做到多表并发复制。因此在较大并发负载时，slav
深入浅出讲解MySQL的并行复制
09-09
主要给大家介绍了关于MySQL并行复制的相关资料，文中通过示例代码介绍的非常详细，对大家学习或使用mysql具有一定的参考学习价值，需要的朋友们下面随着小编来一起学习学习吧
mysql skipslavestart_slave复制进程不随mysql启动而启动skip-slave-start参数_MySQL
weixin_39589766的博客
01-19 891
bitsCN.comslave复制进程不随mysql启动而启动skip-slave-start参数不管怎么说今天采坑了。有一套主从，前期my.cnf配置文件中指定只复制其中某些库，后来因为业务需求，要把未复制的库也开始复制。今天修改完my.cnf配置文件，然后重启数据库，悲催的事情发生了，slave跟着也开始起来了，然后开始复制了，然后造成数据不一致。关键是从库slave要进行reset slav...
mysql的skip-slave-start参数
热门推荐
csdn's blog
05-02 1万+
想起之前在本地做实验的时候，mysql的slave库启动后，复制进程不是双Yes，而是都是No. 今天有空来查查这方面的细节资料，先来官方看看：https://dev.mysql.com/doc/refman/5.7/en/replication-options-replica.html，看到有这个--skip-slave-start参数，简单描述如下： 看描述，参数功能很简洁明了，就是启动slave从库的时候，复制线程不会随着mysql进程启动而开启，如果你需要启动就需要手动执行start s...
mysql skipslavestart_mysql8 参考手册--START SLAVE语句
weixin_39605296的博客
01-27 412
START SLAVE [thread_types] [until_option] [connection_options] [channel_option]thread_types:[thread_type [, thread_type] ... ]thread_type:IO_THREAD | SQL_THREADuntil_option:UNTIL { {SQL_BEFORE_GTIDS...
mysql skipslavestart_skip-slave-start的重要性
weixin_31001069的博客
01-19 807
原来做复制的主机因为数据丢失需要重新创建复制环境，机器上已经有了主库数天前的备份，于是删除数据目录直接把备份放上去，结果发现复制没有抱错，show slave status一切正常，select count(*)某张大表也是不断增加，但是查询该表的max id确迟迟不动。于是把这条最大的数据拿出来看，发现数据是今天的。而slave的同步信息显示才读取到2天前的binlog而已。这台机器既做slav...
mysql主从之slave-skip-errors和sql_slave_skip_counter
weixin_34238633的博客
01-05 317
一般来说，为了保险起见，在主从库维护中，有时候需要跳过某个无法执行的命令，需要在slave处于stop状态下，执行 set global sql_slave_skip_counter=1以跳过命令。但在测试和开发环境下，有时候为了快速解决不影响开发，需要使用set global sql_slave_skip_counter=N，其意思即为在start slave时，从当前位置起，跳过N个event...
快速搞定Mysql8.0主从复制
08-27
快速搞定Mysql8.0主从复制
MySql GTID主从复制
花飘万家雪
04-21 5128
目录 1.GTID介绍 1.1GTID是什么 1.2 GTID Replication介绍 1.3 GTID的组成 1.4GTID的作用 1.5为什么要用GTID 1.6GTID比传统复制的优势 1.7GTID复制实现的工作原理 2 主从复制 2.1 一主一从 2.1.1部署数据库可查看 2.1.2 授权一个用户，用于主从复制主从> 2.1.3 修改master主配文件 2.1.4 slave主配文件 2.1.5 配置slave主机，授权从数据库 2.1.6 验证主...
mysql篇-主从复制常见错误（更新中）
qq_19676401的博客
12-13 1797
mysql场景主从复制报错处理：1032、1062、1864、1236等
这套方法论，彻底终结MySQL同步延迟问题！
bobo now~
11-13 502
这套方法论，彻底终结MySQL同步延迟问题！
MySQL集群：主从模式
weixin_37672801的博客
11-23 1561
数据可以从一个MySQL数据库主节点复制到多个从节点(异步复制)。
mysql skip slave_mysql – 选项–skip-slave-start不使用Systemctl
weixin_39890814的博客
02-26 306
我刚开始使用centos 7.我正在尝试让复制正常工作,并且我试图在不启动slave的情况下启动mysql(这样我就可以设置指针,指示它在启动之前应该恢复复制的位置).通常我会这样做：/etc/init.d/mysqld start --skip-slave-start使用centos 7,我需要使用systemctl来启动mysql,所以我认为等效的命令是：systemctl start mys...
【MySql】sql_slave_skip_counter 参数的用法解析
cojm55771的博客
02-19 475
前一篇文章介绍了当mysql的复制出现slave sql 进程终止时的解决办法，其中之一使用了sql_slave_skip_counter 来使sql 线程跳过遇到错误的事件记录！本文浅析一下sql_slave_...
--skip-slave-start的重要性
cishui7245的博客
02-02 332
一次问题解决过程[@more@] 原来做复制的主机因为数据丢失需要重新创建复制环境，机器上已经有了主库数天前的备份，于是删除数据目录直接把备份放上去，结果发现复制没有抱错，show slave status一切正常，s...
mysql skipslavestart_--skip-slave-start的重要性
weixin_36002475的博客
01-19 373
一次问题解决过程[@more@]原来做复制的主机因为数据丢失需要重新创建复制环境，机器上已经有了主库数天前的备份，于是删除数据目录直接把备份放上去，结果发现复制没有抱错，show slave status一切正常，select count(*)某张大表也是不断增加，但是查询该表的max id确迟迟不动。于是把这条最大的数据拿出来看，发现数据是今天的。而slave的同步信息显示才读取到2天前的bin...
slave_parallel_workers
最新发布
04-06
b'slave_parallel_workers' 是一个用于 PostgreSQL 数据库的参数，表示在主数据库上执行并行复制流的从数据库的最大数量。这个参数可以用来控制从数据库的负载。通常情况下，这个参数的值应该是主数据库上并行复制 Stream 的总数量的一半。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值