精华内容
下载资源
问答
  • mycat数据同步

    2021-01-28 14:18:17
    mysql5.7支持两种事务同步主从复制有两种方式:基于日志(binlog)、基于 GTID(全局事务标示符)。本次采用基于日志(binlog)的方式。在以前的mysql版本中,读写分离的实现一般都是基于日志的主从复制实现的,这样会产生...

    mysql5.7支持两种事务同步

    主从复制有两种方式:基于日志(binlog)、基于 GTID(全局事务标示符)。本次采用基于日志(binlog)的方式。

    在以前的mysql版本中,读写分离的实现一般都是基于日志的主从复制实现的,这样会产生一个问题,就是master宕机之后,slave由于同步延时的问题,会导致master和slave内容不同,甚至会多个slave之间互相不同。所以为了解决这个问题,再mysql5.7.6版本之后加入了基于GTID的事务控制,具体的说就是每个事务由一个唯一的gtid标识,当slave都成功执行之后master才写入硬盘完成该事务,如果master突然宕机,那么就自动回滚。数据的一致性得到保证。

    操作方法和普通的基于日志的主从复制差不了很多,主要就是打开两个开关

    enforce_gtid_consistency = ON

    gtid_mode = ON

    那么就具体的介绍一下这种主从同步的搭建过程。

    Master:

    首先要修改mysql的配置文件,我这里的配置文件路径为/etc/mysql/mysql.conf.d/mysqld.cnf,基于docker,不同的版本位置可能会不一样,windows下多数都叫my.cnf,下载地址:https://hub.docker.com/r/alexzhuo/mysql/。

    这里只截取要修改的那一段

    修改前:

    #server-id = 1

    #log_bin = /var/log/mysql/mysql-bin.log

    expire_logs_days = 10

    max_binlog_size = 100M

    #binlog_do_db = include_database_name

    #binlog_ignore_db = include_database_name

    修改后

    server-id = 1

    log_bin = /var/log/mysql/mysql-bin.log

    expire_logs_days = 10

    max_binlog_size = 100M

    #binlog_do_db = include_database_name

    #binlog_ignore_db = include_database_name

    其实就是去掉了两个注释,打开了binlog,必须打开binlog主从之间同步才有据可依。

    其中server-id是这个mysql集群中,每个节点都要有自己的id,不能重复,一般master设置为1,slave设置为2,3,4,5.如果这一行被注释掉了,那么slave节点是启动不起来的。

    关于binlog_do_db,它是制定哪些库的操作会写入到binlog中,也就是同步哪些库,而binlog_ignore_db是哪些库不写入到binlog中,也就是不同步哪些库。一般情况下可以把这两行注释掉,也就是同步所有的库。在slave节点中也会有这样的配置,但是配置的字段不一样,在slave端进行控制可以降低master的压力,同时还可以精确到某个表是否同步,所以一般在slave节点上进行设置,可见下图:

    然后再查看一下同步格式

    mysql> show global variables like 'binlog%';

    +-----------------------------------------+--------------+

    | Variable_name | Value |

    +-----------------------------------------+--------------+

    | binlog_cache_size | 32768 |

    | binlog_checksum | CRC32 |

    | binlog_direct_non_transactional_updates | OFF |

    | binlog_error_action | ABORT_SERVER |

    | binlog_format | ROW |

    | binlog_group_commit_sync_delay | 0 |

    | binlog_group_commit_sync_no_delay_count | 0 |

    | binlog_gtid_simple_recovery | ON |

    | binlog_max_flush_queue_time | 0 |

    | binlog_order_commits | ON |

    | binlog_row_image | FULL |

    | binlog_rows_query_log_events | OFF |

    | binlog_stmt_cache_size | 32768 |

    +-----------------------------------------+--------------+

    13 rows in set (0.00 sec)

    注意这里的binlog_format是个重点,再mysql 5.7版本中,有三种模式,分别是

    可以根据自己的需要进行选择,默认是row。

    然后我们需要在master节点上创建一个用户,然后给它授权专门用来做复制任务,但是它不能select或者修改任何一张表。语句如下:

    create user 'dba'@'%' identified by '123456';

    grant replication slave on *.* to dba;

    然后我们就可以将当前数据库的所有内容导出出来,然后导入新的数据库里。当然新的slave数据库也是个docker。导出语句如下

    mysqldump --single-transaction --master-data=2 --triggers --routines --all-databases -uroot -p > all.sql

    导出的内容为文本文件。

    如果没有将server-id以及log_bin的注释打开,那么在导出数据库的时候就会报如下错误

    root@701cc1949c81:/home/mysql# mysqldump --single-transaction --master-data=2 --triggers --routines --all-databases -uroot -p > all.sql

    Enter password:

    mysqldump: Error: Binlogging on server not active

    这时只需要按照上面讲的打开binlog然后重启mysql即可。

    然后我们就可以再开启一个新的docker,然后导入这个库,当然你首先要把刚才导出的all.sql传输到新docker容器上,导入语句为:

    mysql -uroot -p < all.sql

    然后作为从数据库,我们也要注意两个配置的地方

    1是server-id,也要打开,并且不能和master的重复,方法跟上面一样,修改/etc/mysql/mysql.conf.d/mysqld.cnf这个文件。

    修改前

    #server-id = 1

    #log_bin = /var/log/mysql/mysql-bin.log

    expire_logs_days = 10

    max_binlog_size = 100M

    #binlog_do_db = include_database_name

    #binlog_ignore_db = include_database_name

    修改后

    server-id = 2

    #log_bin = /var/log/mysql/mysql-bin.log

    expire_logs_days = 10

    max_binlog_size = 100M

    #binlog_do_db = include_database_name

    #binlog_ignore_db = include_database_name

    与master不同的是,只修改server-id这一项就可以了,因为slave不需要开启binlog。

    2、我们还要修改数据库的UUID,否则启动slave的时候会报错。由于master和slave都是通过同一个docker镜像产生的,所以UUID默认是同一个,需要修改配置文件。

    查看当前mysql UUID的命令

    mysql> show variables like '%server_uuid%';

    +---------------+--------------------------------------+

    | Variable_name | Value |

    +---------------+--------------------------------------+

    | server_uuid | b790fa18-404a-11e7-b542-0242ac110002 |

    +---------------+--------------------------------------+

    解决这个问题的方法是修改/var/lib/mysql/auto.cnf这个文件中的UUID,只要和其他master,slave不同即可,然后重启数据库。如果master和slave不一样,那么start slave之后主从I/O无法进行,并且会报错如下

    mysql> show slave status \G

    *************************** 1. row ***************************

    Slave_IO_State:

    Master_Host: 172.17.0.3

    Master_User: dba

    Master_Port: 3306

    Connect_Retry: 60

    Master_Log_File: mysql-bin.000001

    Read_Master_Log_Pos: 154

    Relay_Log_File: 6b901656c610-relay-bin.000001

    Relay_Log_Pos: 4

    Relay_Master_Log_File: mysql-bin.000001

    Slave_IO_Running: No

    Slave_SQL_Running: Yes

    ......

    Last_IO_Error: Fatal error: The slave I/O thread stops because master and slave have equal MySQL server UUIDs; these UUIDs must be different for replication to work.

    Last_SQL_Errno: 0

    Last_SQL_Error:

    ......

    1 row in set (0.00 sec)

    这些都做好之后,我们就可以让slave准备开始同步了,指令如下

    change master to master_host='Master的IP地址',

    -> master_user='dba',

    -> master_password='123456',

    -> master_log_file='binlog文件名',

    -> master_log_pos=数字;

    第一行要知道master的IP地址和端口,如果是3306端口那么只填写IP地址即可,对于docker容器,可以通过下面命令查找IP

    docker inspect

    ......

    "Networks": {

    "bridge": {

    "IPAMConfig": null,

    "Links": null,

    "Aliases": null,

    "NetworkID": "cada7bb270b98235a23771daa68c16a0393bf7acdbf9beea824381c0565e716b",

    "EndpointID": "195ec54ec8fa862dc45d0ac35db9ece1474276b355eec97bf5186bc72dbe6e7d",

    "Gateway": "172.17.0.1",

    "IPAddress": "172.17.0.3",

    "IPPrefixLen": 16,

    "IPv6Gateway": "",

    "GlobalIPv6Address": "",

    "GlobalIPv6PrefixLen": 0,

    "MacAddress": "02:42:ac:11:00:03",

    "DriverOpts": null

    }

    }

    这样就可以看到某个容器的IP了,如果你的容器部署在两台机器上,那么你直接做端口映射即可。

    master_log_file这个参数一般为binlog.00001(新数据库)或者binlog.0000X(X是自然数,并且会随着时间的推移逐渐增大)。要获取这个binlog的文件名,我们可以去查找刚刚导出的all.sql这个文件,这里面有相关记载,如下

    --

    -- Position to start replication or point-in-time recovery from

    --

    -- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=154;

    或者在你手动同步master或者slave数据之后(比如sql导入或者直接拷贝数据库文件),可以在master端通过命令看到,如下

    mysql> show master status \G

    *************************** 1. row ***************************

    File: mysql-bin.000001

    Position: 154

    Binlog_Do_DB:

    Binlog_Ignore_DB:

    1 row in set (0.00 sec)

    这个文件中的MASTER_LOG_FILE对应master_log_file这个参数,MASTER_LOG_POS对应master_log_pos这个参数。于是我的配置命令就变成了:

    change master to master_host='172.17.0.3',

    -> master_user='dba',

    -> master_password='123456',

    -> master_log_file='mysql-bin.000001',

    -> master_log_pos=154;

    如果执行成功,可以检查一下是否配置正确,方法是:

    mysql> show slave status \G

    *************************** 1. row ***************************

    Slave_IO_State:

    Master_Host: 172.17.0.3

    Master_User: dba

    Master_Port: 3306

    Connect_Retry: 60

    Master_Log_File: mysql-bin.000001

    Read_Master_Log_Pos: 154

    Relay_Log_File: 6b901656c610-relay-bin.000001

    Relay_Log_Pos: 4

    Relay_Master_Log_File: mysql-bin.000001

    Slave_IO_Running: No

    Slave_SQL_Running: No

    Replicate_Do_DB:

    Replicate_Ignore_DB:

    Replicate_Do_Table:

    ......

    这里面最重要的两个参数是Slave_IO_Running和Slave_SQL_Running,由于当前还没有开启slave节点,所以两个都是NO,可以通过下面命令开启

    start slave;

    开启之后,上面两个字段如果均为yes说明slave节点同步成功。如果还有NO,那么把报错会显示在Last_IO_Error字段,如下

    mysql> show slave status \G

    *************************** 1. row ***************************

    Slave_IO_State:

    Master_Host: 172.17.0.3

    Master_User: dba

    Master_Port: 3306

    Connect_Retry: 60

    Master_Log_File: mysql-bin.000001

    Read_Master_Log_Pos: 154

    Relay_Log_File: 6b901656c610-relay-bin.000001

    Relay_Log_Pos: 4

    Relay_Master_Log_File: mysql-bin.000001

    Slave_IO_Running: No

    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: 154

    Relay_Log_Space: 154

    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: NULL

    Master_SSL_Verify_Server_Cert: No

    Last_IO_Errno: 1593

    Last_IO_Error: Fatal error: The slave I/O thread stops because master and slave have equal MySQL server UUIDs; these UUIDs must be different for replication to work.

    Last_SQL_Errno: 0

    Last_SQL_Error:

    Replicate_Ignore_Server_Ids:

    Master_Server_Id: 1

    Master_UUID:

    Master_Info_File: /var/lib/mysql/master.info

    SQL_Delay: 0

    SQL_Remaining_Delay: NULL

    Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates

    Master_Retry_Count: 86400

    Master_Bind:

    Last_IO_Error_Timestamp: 180527 08:16:18

    Last_SQL_Error_Timestamp:

    Master_SSL_Crl:

    Master_SSL_Crlpath:

    Retrieved_Gtid_Set:

    Executed_Gtid_Set:

    Auto_Position: 0

    Replicate_Rewrite_DB:

    Channel_Name:

    Master_TLS_Version:

    1 row in set (0.00 sec)

    当然这个问题上面已经提供了解决方案。

    当Slave_IO_Running和Slave_SQL_Running都是yes后,我们就可以再master节点执行建库,建表,insert,update操作,然后再slave上查看是否同步了数据。

    上面已经完成了传统的基于日志的主从复制,下面要开启mysql 5.7的新特性,基于事务的复制,其主要的操作就两点

    1、在master和slave上都开启enforce_gtid_consistency

    2、在master和slave上都开启gtid_mode

    我们在master和slave上均执行下面的操作

    首先检查一下是否已经开启了gtid,如果返回是empty那么说明还灭有开启

    mysql> show variables like 'grid_mode';

    Empty set (0.00 sec)

    然后我们执行下面的命令进行开启

    set @@global.enforce_gtid_consistency=warn;

    set @@global.enforce_gtid_consistency=on;

    为什么一个set语句要执行两遍呢,因为这个参数不允许直接从off设置成on,而要off-warn-on的转变的过程。设置完之后,我们查看一下errorlog看有无报错

    tail -f /var/log/mysql/error.log

    2018-05-27T07:58:22.327301Z 0 [Warning] 'proxies_priv' entry '@ root@localhost' ignored in --skip-name-resolve mode.

    2018-05-27T07:58:22.328919Z 0 [Warning] 'tables_priv' entry 'sys_config mysql.sys@localhost' ignored in --skip-name-resolve mode.

    2018-05-27T07:58:22.340490Z 0 [Note] Event Scheduler: Loaded 0 events

    2018-05-27T07:58:22.341126Z 0 [Note] /usr/sbin/mysqld: ready for connections.

    Version: '5.7.18-0ubuntu0.16.04.1-log' socket: '/var/run/mysqld/mysqld.sock' port: 3306 (Ubuntu)

    2018-05-27T07:58:22.341233Z 0 [Note] Executing 'SELECT * FROM INFORMATION_SCHEMA.TABLES;' to get a list of tables using the deprecated partition engine. You may use the startup option '--disable-partition-engine-check' to skip this check.

    2018-05-27T07:58:22.341274Z 0 [Note] Beginning of list of non-natively partitioned tables

    2018-05-27T07:58:22.366089Z 0 [Note] End of list of non-natively partitioned tables

    2018-05-27T08:19:47.238163Z 9 [Note] Start binlog_dump to master_thread_id(9) slave_server(2), pos(mysql-bin.000001, 154)

    2018-05-27T08:37:15.629583Z 8 [Note] Changed ENFORCE_GTID_CONSISTENCY from OFF to WARN.

    没有报错就可以查看一下是否成功,然后继续下面的操作了

    show global variables like 'enforce_gtid%';

    +--------------------------+-------+

    | Variable_name | Value |

    +--------------------------+-------+

    | enforce_gtid_consistency | ON |

    +--------------------------+-------+

    set @@global.gtid_mode = off_permissive;

    set @@global.gtid_mode = on_permissive;

    set @@global.gtid_mode = on;

    同理,global.gtid_mode这个参数也必须以off-off_permissive-on_permissive-on的过程变化,设置完之后我们同样需要查看一下有无报错日志,然后检查一下是否开启。

    show variables like 'gtid_mode';

    +---------------+-------+

    | Variable_name | Value |

    +---------------+-------+

    | gtid_mode | ON |

    +---------------+-------+

    在master和所有slave节点都执行上述命令之后,master节点无需重启。但是slave节点需要重启slave模式,如下

    mysql> stop slave;

    Query OK, 0 rows affected (0.05 sec)

    mysql> change master to master_auto_position=1;

    Query OK, 0 rows affected (0.31 sec)

    mysql> start slave;

    Query OK, 0 rows affected (0.03 sec)

    这样就完成了slave节点的重启。然后我们立即执行命令观察一下相关参数

    mysql> show slave status \G

    *************************** 1. row ***************************

    Slave_IO_State: Waiting for master to send event

    Master_Host: 172.17.0.3

    Master_User: dba

    Master_Port: 3306

    Connect_Retry: 60

    Master_Log_File: mysql-bin.000004

    Read_Master_Log_Pos: 154

    Relay_Log_File: 6b901656c610-relay-bin.000002

    Relay_Log_Pos: 367

    Relay_Master_Log_File: mysql-bin.000004

    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: 154

    Relay_Log_Space: 581

    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: b790fa18-404a-11e7-b542-0242ac110002

    Master_Info_File: /var/lib/mysql/master.info

    SQL_Delay: 0

    SQL_Remaining_Delay: NULL

    Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates

    Master_Retry_Count: 86400

    Master_Bind:

    Last_IO_Error_Timestamp:

    Last_SQL_Error_Timestamp:

    Master_SSL_Crl:

    Master_SSL_Crlpath:

    Retrieved_Gtid_Set:

    Executed_Gtid_Set:

    Auto_Position: 1

    Replicate_Rewrite_DB:

    Channel_Name:

    Master_TLS_Version:

    1 row in set (0.00 sec)

    发现和基于日志也没什么不同,只是Master_UUID变成了master节点上/var/lib/mysql/auto.cnf这个文件里写的UUID了。但是当我们再master上执行一下insert或者其他写入操作后,Executed_Gtid_Set这一参数就会有值,而且适合Master_UUID有关联的一个值。更是基于gtid复制是否成功的标志。如下

    mysql> show slave status \G

    *************************** 1. row ***************************

    Slave_IO_State: Waiting for master to send event

    Master_Host: 172.17.0.3

    Master_User: dba

    Master_Port: 3306

    Connect_Retry: 60

    Master_Log_File: mysql-bin.000004

    Read_Master_Log_Pos: 411

    Relay_Log_File: 6b901656c610-relay-bin.000002

    Relay_Log_Pos: 624

    Relay_Master_Log_File: mysql-bin.000004

    Slave_IO_Running: Yes

    Slave_SQL_Running: Yes

    ......

    Retrieved_Gtid_Set: b790fa18-404a-11e7-b542-0242ac110002:1

    Executed_Gtid_Set: b790fa18-404a-11e7-b542-0242ac110002:1

    Auto_Position: 1

    Replicate_Rewrite_DB:

    Channel_Name:

    Master_TLS_Version:

    1 row in set (0.01 sec)

    然后我们检查一下相关建库建表插入操作是否同步成功即可。

    注意,如果按照上面的配置,手动将enforce_gtid_consistency和gtid_mode设置为ON之后,如果你重启了容器或者mysql服务,再次启动时会发现没有自动同步,Slave_IO_Running和Slave_SQL_Running都是NO,start slave时会报错,如下

    mysql> show slave status \G

    *************************** 1. row ***************************

    Slave_IO_State:

    Master_Host: 172.17.0.3

    Master_User: dba

    Master_Port: 3306

    Connect_Retry: 60

    Master_Log_File: mysql-bin.000004

    Read_Master_Log_Pos: 411

    Relay_Log_File: 6b901656c610-relay-bin.000002

    Relay_Log_Pos: 624

    Relay_Master_Log_File: mysql-bin.000004

    Slave_IO_Running: No

    Slave_SQL_Running: No

    mysql> start slave

    -> ;

    ERROR 3112 (HY000): The replication receiver thread for channel '' cannot start in AUTO_POSITION mode: this server uses @@GLOBAL.GTID_MODE = OFF.

    这是因为重启mysql服务后需要重新按照上面的方法手动设置enforce_gtid_consistency和gtid_mode为ON,当然这样太麻烦了,应该写在mysql配置文件my.cnf里,这样每次启动就会自动开启同步模式,无需再手动执行任何命令。方法就是再my.cnf文件末尾加入

    vi /etc/mysql/mysql.conf.d/mysqld.cnf

    ......

    enforce_gtid_consistency = ON

    gtid_mode = ON

    当你把master和slave两个docker保存好,迁移到其他机器上或者宕机重启之后,或者master更换IP之后,你会发现slave端经常起不来。报错如下

    mysql> start slave;

    ERROR 1872 (HY000): Slave failed to initialize relay log info structure from the repository

    这是因为master或者slave重启之后,原先的binlog就对不上了,需要我们手动重置slave节点,master不用动,好在gtid的设置不用再来一遍了,slave端执行如下命令。

    mysql> reset slave;

    mysql> start slave;

    注意,由于上面在开启gtid模式的时候设置了

    change master to master_auto_position=1;

    语句,所以如果此时重新执行change master语句,那么里面的

    -> master_log_file='binlog文件名',

    -> master_log_pos=数字;

    会导致不能成功,因为gtid模式下,会自动的同步这两个参数,如果实在想通过手动方式设置binlog的位置的行数,那么需要先change master to master_auto_position=0;

    由于gtid模式下不需要填binlog文件名和行数了,如果你的master节点IP变化了,那么只需重新设置master的IP即可,注意之后还要reset slave和start slave;

    change master to master_host='Master的IP地址',

    -> master_user='dba',

    -> master_password='123456'

    reset slave;

    start slave;

    一步到位直接开启GTID模式

    上面提供的方案中,是先开启普通的日志复制模式,然后再采用基于GTID的复制模式,如何一步到位直接开启gtid模式呢。方法其实很简单,因为在gtid模式下,可以自动定位master binlog的文件名和行数,所以省去了去master服务器查看的麻烦。只要master和slave数据首先一模一样(通过mysqldump导入),同时master没有任何操作(需要将3306上所有连接都断开)。然后直接使用change master命令即可。详细过程如下

    1、Master的配置还和上面一样。需要打开binlog,并开启enforce_gtid_consistency和gtid_mode(如果嫌每次启动master都要手动开启太麻烦,那么就把这两项写到my.cnf中,上面有提到)

    2、Slave的配置文件my.cnf中加入

    enforce_gtid_consistency = ON

    gtid_mode = ON

    并且别忘了修改serverid

    server-id = 2

    启动之后,通过change master语句设置master的IP地址,无需设置binlog的位置和行数,只需保证目前的库和master库内容一致即可

    change master to master_host='Master的IP地址',

    -> master_user='dba',

    -> master_password='123456'

    start slave;

    然后再检查一下是否都是yes即可

    mysql> show slave status \G

    ---------------------

    版权声明:本文为CSDN博主「lvshaorong」的原创文章,遵循CC 4.0 by-sa版权协议,转载请附上原文出处链接及本声明。

    原文链接:https://blog.csdn.net/lvshaorong/article/details/80471878

    展开全文
  • java 定时同步数据的任务优化

    千次阅读 2021-03-08 02:49:46
    前言定时任务在系统中并不少见,主要目的是用于需要定时处理数据或者执行某个操作的情况下,如定时关闭订单,或者定时备份。而常见的定时任务分为2种,第一种:固定时间执行,如:每分钟执行一次,每天执行一次。第...

    前言

    定时任务在系统中并不少见,主要目的是用于需要定时处理数据或者执行某个操作的情况下,如定时关闭订单,或者定时备份。而常见的定时任务分为2种,第一种:固定时间执行,如:每分钟执行一次,每天执行一次。第二种:延时多久执行,就是当发生一件事情后,根据这件时间发生的时间定时多久后执行任务,如:15分钟后关闭订单付款状态,24小时候后关闭订单并且释放库存,而由于第二种一般都是单一数据的处理(主要是指数据量不大,一般情况下只有一个主体处理对象,如:一个订单以及订单中的N个商品),所以一般情况下第二种出现性能问题的几率不大(不代表没有),所以本文主要是针对第一种定时任务来进行优化,而且主要是针对数据同步或者传递数据来进行优化,而优化的方式也是根据实际项目中的情况在不同阶段进行优化的

    第一阶段

    第一阶段属于原始阶段,逻辑也最为简单,由于同步分为数据同步和传递数据,而且2种的需求各不一致(主要是在于是否允许丢失),所以分开分析

    第一种类型:传递数据

    由于传递数据可以允许丢失,常见的场景如调用凭证推送(常见于接口需要暴露给第三方,为了安全性,可以定时推送调用凭证来保证接口安全性),消息推送(订单消费成功后推送消息,由于可能推送失败,所以需要进入定时任务进行重试,但是因为消息实时性,所以重试到一定次数后放弃重试)

    传递数据在第一阶段设计非常简单,定时推送,有限的错误次数,同步成功后修改状态,同步失败后对失败次数+1,一旦超过错误次数,就不在继续尝试</

    展开全文
  • 也就是说两域控之间没有进行数据同步了。查看事件日志,提示数据复制失败等等。然后还发现备域控上的DNS的正向和反向搜索区域信息都是空的。原本打算把备域控降域,但是在降的过程中提示无法连接操作主机!怎么办...

    这段时间突然发现域中的帐户有时候无法登陆到域,重启后可能又可以登陆到域,有时候重启一次还不行。然后查看域控制器,发现主备域控上的数据不一致。主域控上有的用户在备域控上没有。也就是说两台域控之间没有进行数据同步了。查看事件日志,提示数据复制失败等等。然后还发现备域控上的DNS的正向和反向搜索区域信息都是空的。原本打算把备域控降域,但是在降的过程中提示无法连接操作主机!怎么办?请高手给出解决办法!

    相关截图:

    5bf13591ea5a7735f908e69e22dcf7d3.png

    10f60cde4d1b217fa6f2830c751d83bd.png

    主域控上报错:此计算机与命名的源计算机上一次复制后的时间间隔太长。 与此源的复制间隔时间已经超过 tombstone 生存时间。 与该源的复制已经停止。

    不允许继续复制的原因是删除的对象在这两台计算机上的 视图可能不同。源计算机可能仍然保留了在此计算机上已经 被删除的(并垃圾收集的)对象的副本。如果允许复制,源计算机可能返回 已经删除的对象。

    上一次成功复制的时间:

    2011-05-21 11:09:59

    源调用 ID:

    0803f6c8-f6b8-0803-0100-000000000000

    源名称:

    e99c9590-8383-455a-a68b-b4996d1050ac._msdcs.fxdt.com

    Tombstone 生存时间(天):

    60

    复制操作已经失败。

    用户操作:

    确定两台计算机中哪一台已经从林断开并过期。 您有三个选择:

    1. 降级或重新安装断开的计算机。

    2. 使用 "repadmin /removelingeringobjects" 工具来删除不一致的已删除对象, 然后继续复制。

    3. 继续复制。可能导致不一致的已删除对象。您可以通过使用下列注册表项来继续复制。 一旦系统复制了一次,强烈建议您删除该项以重新设置保护。

    注册表项:

    HKLM\System\CurrentControlSet\Services\NTDS\Parameters\Allow Replication With Divergent and Corrupt Partner

    盼回复!!!!!!

    展开全文
  • 单位上的域控平台正常运行一年后,某天发现主域和辅助域服务器数据不能同步,经检查网络连接正常,135、139、445等共享端口正常开启,用dcdiag命令检测主域服务器后,报告如下:C:\Users\Administrator>...

    单位上的域控平台正常运行一年后,某天发现主域和辅助域服务器数据不能同步,经检查网络连接正常,135、139、445等共享端口正常开启,用dcdiag命令检测主域服务器后,报告如下:

    C:\Users\Administrator>dcdiag

    目录服务器诊断

    正在执行初始化设置:

    正在尝试查找主服务器...

    主服务器 = hhad1

    * 已识别的 AD 林。

    已完成收集初始化信息。

    正在进行所需的初始化测试

    正在测试服务器: Default-First-Site-Name\HHAD1

    开始测试: Connectivity

    ......................... HHAD1 已通过测试 Connectivity

    正在执行主要测试

    正在测试服务器: Default-First-Site-Name\HHAD1

    开始测试: Advertising

    ......................... HHAD1 已通过测试 Advertising

    开始测试: FrsEvent

    ......................... HHAD1 已通过测试 FrsEvent

    开始测试: DFSREvent

    ......................... HHAD1 已通过测试 DFSREvent

    开始测试: SysVolCheck

    ......................... HHAD1 已通过测试 SysVolCheck

    开始测试: KccEvent

    ......................... HHAD1 已通过测试 KccEvent

    开始测试: KnowsOfRoleHolders

    ......................... HHAD1 已通过测试 KnowsOfRoleHolders

    开始测试: MachineAccount

    ......................... HHAD1 已通过测试 MachineAccount

    开始测试: NCSecDesc

    ......................... HHAD1 已通过测试 NCSecDesc

    开始测试: NetLogons

    ......................... HHAD1 已通过测试 NetLogons

    开始测试: ObjectsReplicated

    ......................... HHAD1 已通过测试 ObjectsReplicated

    开始测试: Replications

    [Replications Check,HHAD1] 最近的复制尝试失败:

    从 HHAD2 到 HHAD1

    命名上下文: DC=hhycad,DC=com

    复制生成一个错误(8606):

    没有给定足够的属性以创建对象。这个对象可能不存在因为它可能已经删除域

    垃圾收集。

    失败发生在 2020-02-19 15:49:12。

    上次成功发生在 2019-09-28 14:51:58。

    自从上次成功已发生 3460 次失败。

    ......................... HHAD1 没有通过测试 Replications

    开始测试: RidManager

    ......................... HHAD1 已通过测试 RidManager

    开始测试: Services

    ......................... HHAD1 已通过测试 Services

    开始测试: SystemLog

    发生了一个错误事件。EventID: 0x0000165B

    生成时间: 02/19/2020   15:54:49

    事件字符串:

    从计算机 'MLBGSGY01' 设置会话失败,因为安全数据库 没有包含指定计算机

    引用的信任帐户 'MLBGSGY01$'。

    发生了一个错误事件。EventID: 0x000016AD

    生成时间: 02/19/2020   15:56:53

    事件字符串: 从计算机 MLBGSGY01 设置的会话未能进行身份验证。 发生下列

    错误:

    ......................... HHAD1 没有通过测试 SystemLog

    开始测试: VerifyReferences

    ......................... HHAD1 已通过测试 VerifyReferences

    正在 ForestDnsZones

    上运行分区测试

    开始测试: CheckSDRefDom

    ......................... ForestDnsZones 已通过测试 CheckSDRefDom

    开始测试: CrossRefValidation

    ......................... ForestDnsZones 已通过测试 CrossRefValidation

    正在 DomainDnsZones

    上运行分区测试

    开始测试: CheckSDRefDom

    ......................... DomainDnsZones 已通过测试 CheckSDRefDom

    开始测试: CrossRefValidation

    ......................... DomainDnsZones 已通过测试 CrossRefValidation

    正在 Schema

    上运行分区测试

    开始测试: CheckSDRefDom

    ......................... Schema 已通过测试 CheckSDRefDom

    开始测试: CrossRefValidation

    ......................... Schema 已通过测试 CrossRefValidation

    正在 Configuration

    上运行分区测试

    开始测试: CheckSDRefDom

    ......................... Configuration 已通过测试 CheckSDRefDom

    开始测试: CrossRefValidation

    ......................... Configuration 已通过测试 CrossRefValidation

    正在 hhycad

    上运行分区测试

    开始测试: CheckSDRefDom

    ......................... hhycad 已通过测试 CheckSDRefDom

    开始测试: CrossRefValidation

    ......................... hhycad 已通过测试 CrossRefValidation

    正在 hhycad.com

    上运行企业测试

    开始测试: LocatorCheck

    ......................... hhycad.com 已通过测试 LocatorCheck

    开始测试: Intersite

    ......................... hhycad.com 已通过测试 Intersite

    另外辅助域服务器的DNS功能模块也不正常(不让上图)

    辅助域服务器上运行dcdiag命令,结果如下:

    ......................... HHAD2 没有通过测试 DFSREvent

    开始测试: SysVolCheck

    ......................... HHAD2 已通过测试 SysVolCheck

    开始测试: KccEvent

    ......................... HHAD2 已通过测试 KccEvent

    开始测试: KnowsOfRoleHolders

    [HHAD1] DsBindWithSpnEx() 失败,错误为 -2146893022,

    目标主要名称不正确。.

    警告: HHAD1 为 Schema Owner,但不对 DS RPC 绑定作出响应。

    [HHAD1] LDAP 绑定失败,错误为 8341,

    出现了一个目录服务错误。.

    警告: HHAD1 为 Schema Owner,但不对 LDAP 绑定作出响应。

    警告: HHAD1 为 Domain Owner,但不对 DS RPC 绑定作出响应。

    警告: HHAD1 为 Domain Owner,但不对 LDAP 绑定作出响应。

    警告: HHAD1 为 PDC Owner,但不对 DS RPC 绑定作出响应。

    警告: HHAD1 为 PDC Owner,但不对 LDAP 绑定作出响应。

    警告: HHAD1 为 Rid Owner,但不对 DS RPC 绑定作出响应。

    警告: HHAD1 为 Rid Owner,但不对 LDAP 绑定作出响应。

    警告: HHAD1 为 Infrastructure Update Owner,但不对 DS RPC 绑定作出响应

    警告: HHAD1 为 Infrastructure Update Owner,但不对 LDAP 绑定作出响应。

    ......................... HHAD2 没有通过测试 KnowsOfRoleHolders

    开始测试: MachineAccount

    ......................... HHAD2 已通过测试 MachineAccount

    开始测试: NCSecDesc

    ......................... HHAD2 已通过测试 NCSecDesc

    开始测试: NetLogons

    [HHAD2] 用户凭据没有权限执行该操作。

    该测试使用的帐户必须具有该计算机的域的

    网络登录权限。

    ......................... HHAD2 没有通过测试 NetLogons

    开始测试: ObjectsReplicated

    ......................... HHAD2 已通过测试 ObjectsReplicated

    开始测试: Replications

    [Replications Check,HHAD2] 最近的复制尝试失败:

    从 HHAD1 到 HHAD2

    命名上下文: DC=ForestDnsZones,DC=hhycad,DC=com

    复制生成一个错误(1256):

    远程系统不可用。有关网络疑难解答,请参阅 Windows 帮助。

    失败发生在 2020-02-19 16:54:07。

    上次成功发生在 2019-03-12 15:59:07。

    自从上次成功已发生 8271 次失败。

    [Replications Check,HHAD2] 最近的复制尝试失败:

    从 HHAD1 到 HHAD2

    命名上下文: DC=DomainDnsZones,DC=hhycad,DC=com

    复制生成一个错误(1256):

    远程系统不可用。有关网络疑难解答,请参阅 Windows 帮助。

    失败发生在 2020-02-19 16:54:07。

    上次成功发生在 2019-03-12 15:59:07。

    自从上次成功已发生 8263 次失败。

    [Replications Check,HHAD2] 最近的复制尝试失败:

    从 HHAD1 到 HHAD2

    命名上下文: CN=Schema,CN=Configuration,DC=hhycad,DC=com

    复制生成一个错误(-2146893022):

    目标主要名称不正确。

    失败发生在 2020-02-19 16:54:07。

    上次成功发生在 2019-03-12 15:59:07。

    自从上次成功已发生 8260 次失败。

    [Replications Check,HHAD2] 最近的复制尝试失败:

    从 HHAD1 到 HHAD2

    命名上下文: CN=Configuration,DC=hhycad,DC=com

    复制生成一个错误(-2146893022):

    目标主要名称不正确。

    失败发生在 2020-02-19 16:54:07。

    上次成功发生在 2019-03-12 15:59:07。

    自从上次成功已发生 8260 次失败。

    [Replications Check,HHAD2] 最近的复制尝试失败:

    从 HHAD1 到 HHAD2

    命名上下文: DC=hhycad,DC=com

    复制生成一个错误(-2146893022):

    目标主要名称不正确。

    失败发生在 2020-02-19 16:54:07。

    上次成功发生在 2019-03-12 16:00:29。

    自从上次成功已发生 8260 次失败。

    ......................... HHAD2 没有通过测试 Replications

    开始测试: RidManager

    ......................... HHAD2 没有通过测试 RidManager

    开始测试: Services

    ......................... HHAD2 已通过测试 Services

    开始测试: SystemLog

    发生了一个错误事件。EventID: 0x40000004

    生成时间: 02/19/2020   16:15:22

    事件字符串:

    Kerberos 客户端收到了来自服务器 hhad2$ 的 KRB_AP_ERR_MODIFIED 错误。

    使用的目标名称为 LDAP/hhad2.hhycad.com/hhycad.com。这表明目标服务器无法解密客户

    端提供的票证。如果不是在目标服务正在使用的帐户上注册目标服务器主体名称(SPN),则

    会出现该问题。请确保仅在服务器使用的帐户上注册目标 SPN。如果目标服务使用的目标服

    务帐户密码与 Kerberos 密钥发行中心上配置的密码不同,也会出现该问题。请确保服务器

    和 KDC 上的服务均配置为使用同一密码。如果服务器名称未完全限定,并且目标域(HHYCAD

    .COM)与客户端域(HHYCAD.COM)不同,则请检查这两个域中是否有相同名称的服务器帐户,

    或使用完全限定的名称标识服务器。

    发生了一个错误事件。EventID: 0x40000004

    生成时间: 02/19/2020   16:24:00

    事件字符串:

    Kerberos 客户端收到了来自服务器 hhad2$ 的 KRB_AP_ERR_MODIFIED 错误。

    使用的目标名称为 LDAP/hhad2.hhycad.com/hhycad.com@HHYCAD.COM。这表明目标服务器无

    法解密客户端提供的票证。如果不是在目标服务正在使用的帐户上注册目标服务器主体名称

    (SPN),则会出现该问题。请确保仅在服务器使用的帐户上注册目标 SPN。如果目标服务使

    用的目标服务帐户密码与 Kerberos 密钥发行中心上配置的密码不同,也会出现该问题。请

    确保服务器和 KDC 上的服务均配置为使用同一密码。如果服务器名称未完全限定,并且目

    标域(HHYCAD.COM)与客户端域(HHYCAD.COM)不同,则请检查这两个域中是否有相同名称的服

    务器帐户,或使用完全限定的名称标识服务器。

    发生了一个错误事件。EventID: 0x0000165B

    生成时间: 02/19/2020   16:29:45

    事件字符串:

    从计算机 'HYNYBGS-LTT' 设置会话失败,因为安全数据库 没有包含指定计算

    机引用的信任帐户 'HYNYBGS-LTT$'。

    发生了一个错误事件。EventID: 0x000016AD

    生成时间: 02/19/2020   16:31:58

    事件字符串: 从计算机 HYNYBGS-LTT 设置的会话未能进行身份验证。 发生下

    列错误:

    发生了一个错误事件。EventID: 0x000016AD

    生成时间: 02/19/2020   16:33:50

    事件字符串: 从计算机 MLBGS-LHF 设置的会话未能进行身份验证。 发生下列

    错误:

    发生了一个错误事件。EventID: 0x40000004

    生成时间: 02/19/2020   16:34:08

    事件字符串:

    Kerberos 客户端收到了来自服务器 hhad2$ 的 KRB_AP_ERR_MODIFIED 错误。

    使用的目标名称为 ldap/hhad2.hhycad.com。这表明目标服务器无法解密客户端提供的票证

    。如果不是在目标服务正在使用的帐户上注册目标服务器主体名称(SPN),则会出现该问题

    。请确保仅在服务器使用的帐户上注册目标 SPN。如果目标服务使用的目标服务帐户密码与

    Kerberos 密钥发行中心上配置的密码不同,也会出现该问题。请确保服务器和 KDC 上的

    服务均配置为使用同一密码。如果服务器名称未完全限定,并且目标域(HHYCAD.COM)与客户

    端域(HHYCAD.COM)不同,则请检查这两个域中是否有相同名称的服务器帐户,或使用完全限

    定的名称标识服务器。

    发生了一个错误事件。EventID: 0x40000004

    生成时间: 02/19/2020   16:35:17

    事件字符串:

    Kerberos 客户端收到了来自服务器 hhad2$ 的 KRB_AP_ERR_MODIFIED 错误。

    使用的目标名称为 ldap/hhad2.hhycad.com/hhycad.com@HHYCAD.COM。这表明目标服务器无

    法解密客户端提供的票证。如果不是在目标服务正在使用的帐户上注册目标服务器主体名称

    (SPN),则会出现该问题。请确保仅在服务器使用的帐户上注册目标 SPN。如果目标服务使

    用的目标服务帐户密码与 Kerberos 密钥发行中心上配置的密码不同,也会出现该问题。请

    确保服务器和 KDC 上的服务均配置为使用同一密码。如果服务器名称未完全限定,并且目

    标域(HHYCAD.COM)与客户端域(HHYCAD.COM)不同,则请检查这两个域中是否有相同名称的服

    务器帐户,或使用完全限定的名称标识服务器。

    发生了一个错误事件。EventID: 0x40000004

    生成时间: 02/19/2020   16:38:25

    事件字符串:

    Kerberos 客户端收到了来自服务器 hhad1$ 的 KRB_AP_ERR_MODIFIED 错误。

    使用的目标名称为 E3514235-4B06-11D1-AB04-00C04FC2DCD2/add638e6-1fc9-4795-afdd-86

    addf535285/hhycad.com@hhycad.com。这表明目标服务器无法解密客户端提供的票证。如果

    不是在目标服务正在使用的帐户上注册目标服务器主体名称(SPN),则会出现该问题。请确

    保仅在服务器使用的帐户上注册目标 SPN。如果目标服务使用的目标服务帐户密码与 Kerbe

    ros 密钥发行中心上配置的密码不同,也会出现该问题。请确保服务器和 KDC 上的服务均

    配置为使用同一密码。如果服务器名称未完全限定,并且目标域(HHYCAD.COM)与客户端域(H

    HYCAD.COM)不同,则请检查这两个域中是否有相同名称的服务器帐户,或使用完全限定的名

    称标识服务器。

    发生了一个错误事件。EventID: 0x0000165B

    生成时间: 02/19/2020   16:38:35

    事件字符串:

    从计算机 'SPNJYZ-LJ' 设置会话失败,因为安全数据库 没有包含指定计算机

    引用的信任帐户 'SPNJYZ-LJ$'。

    发生了一个错误事件。EventID: 0x000016AD

    生成时间: 02/19/2020   16:40:47

    事件字符串: 从计算机 SPNJYZ-LJ 设置的会话未能进行身份验证。 发生下列

    错误:

    发生了一个错误事件。EventID: 0x40000004

    生成时间: 02/19/2020   16:41:34

    事件字符串:

    Kerberos 客户端收到了来自服务器 hhad1$ 的 KRB_AP_ERR_MODIFIED 错误。

    使用的目标名称为 DNS/hhad1.hhycad.com。这表明目标服务器无法解密客户端提供的票证

    。如果不是在目标服务正在使用的帐户上注册目标服务器主体名称(SPN),则会出现该问题

    。请确保仅在服务器使用的帐户上注册目标 SPN。如果目标服务使用的目标服务帐户密码与

    Kerberos 密钥发行中心上配置的密码不同,也会出现该问题。请确保服务器和 KDC 上的

    服务均配置为使用同一密码。如果服务器名称未完全限定,并且目标域(HHYCAD.COM)与客户

    端域(HHYCAD.COM)不同,则请检查这两个域中是否有相同名称的服务器帐户,或使用完全限

    定的名称标识服务器。

    发生了一个错误事件。EventID: 0x0000165B

    生成时间: 02/19/2020   16:43:43

    事件字符串:

    从计算机 'GSJGCW-ZBX' 设置会话失败,因为安全数据库 没有包含指定计算

    机引用的信任帐户 'GSJGCW-ZBX$'。

    发生了一个错误事件。EventID: 0x000016AD

    生成时间: 02/19/2020   16:45:44

    事件字符串: 从计算机 GSJGCW-ZBX 设置的会话未能进行身份验证。 发生下

    列错误:

    发生了一个错误事件。EventID: 0x40000004

    生成时间: 02/19/2020   16:47:43

    事件字符串:

    Kerberos 客户端收到了来自服务器 hhad2$ 的 KRB_AP_ERR_MODIFIED 错误。

    使用的目标名称为 LDAP/hhad2.hhycad.com/HHYCAD。这表明目标服务器无法解密客户端提

    供的票证。如果不是在目标服务正在使用的帐户上注册目标服务器主体名称(SPN),则会出

    现该问题。请确保仅在服务器使用的帐户上注册目标 SPN。如果目标服务使用的目标服务帐

    户密码与 Kerberos 密钥发行中心上配置的密码不同,也会出现该问题。请确保服务器和 K

    DC 上的服务均配置为使用同一密码。如果服务器名称未完全限定,并且目标域(HHYCAD.COM

    )与客户端域(HHYCAD.COM)不同,则请检查这两个域中是否有相同名称的服务器帐户,或使

    用完全限定的名称标识服务器。

    发生了一个错误事件。EventID: 0x40000004

    生成时间: 02/19/2020   17:00:03

    事件字符串:

    Kerberos 客户端收到了来自服务器 hhad2$ 的 KRB_AP_ERR_MODIFIED 错误。

    使用的目标名称为 LDAP/HHAD2。这表明目标服务器无法解密客户端提供的票证。如果不是

    在目标服务正在使用的帐户上注册目标服务器主体名称(SPN),则会出现该问题。请确保仅

    在服务器使用的帐户上注册目标 SPN。如果目标服务使用的目标服务帐户密码与 Kerberos

    密钥发行中心上配置的密码不同,也会出现该问题。请确保服务器和 KDC 上的服务均配置

    为使用同一密码。如果服务器名称未完全限定,并且目标域(HHYCAD.COM)与客户端域(HHYCA

    D.COM)不同,则请检查这两个域中是否有相同名称的服务器帐户,或使用完全限定的名称标

    识服务器。

    发生了一个错误事件。EventID: 0x40000004

    生成时间: 02/19/2020   17:03:09

    事件字符串:

    Kerberos 客户端收到了来自服务器 hhad2$ 的 KRB_AP_ERR_MODIFIED 错误。

    使用的目标名称为 cifs/hhad2.hhycad.com。这表明目标服务器无法解密客户端提供的票证

    。如果不是在目标服务正在使用的帐户上注册目标服务器主体名称(SPN),则会出现该问题

    。请确保仅在服务器使用的帐户上注册目标 SPN。如果目标服务使用的目标服务帐户密码与

    Kerberos 密钥发行中心上配置的密码不同,也会出现该问题。请确保服务器和 KDC 上的

    服务均配置为使用同一密码。如果服务器名称未完全限定,并且目标域(HHYCAD.COM)与客户

    端域(HHYCAD.COM)不同,则请检查这两个域中是否有相同名称的服务器帐户,或使用完全限

    定的名称标识服务器。

    发生了一个错误事件。EventID: 0x0000165B

    生成时间: 02/19/2020   17:03:58

    事件字符串:

    从计算机 'YYLDBZ-HWY' 设置会话失败,因为安全数据库 没有包含指定计算

    机引用的信任帐户 'YYLDBZ-HWY$'。

    发生了一个错误事件。EventID: 0x000016AD

    生成时间: 02/19/2020   17:06:00

    事件字符串: 从计算机 YYLDBZ-HWY 设置的会话未能进行身份验证。 发生下

    列错误:

    发生了一个错误事件。EventID: 0x0000165B

    生成时间: 02/19/2020   17:06:33

    事件字符串:

    从计算机 'SPNJYZ-LGA' 设置会话失败,因为安全数据库 没有包含指定计算

    机引用的信任帐户 'SPNJYZ-LGA$'。

    发生了一个错误事件。EventID: 0x000016AD

    生成时间: 02/19/2020   17:09:14

    事件字符串: 从计算机 SPNJYZ-LGA 设置的会话未能进行身份验证。 发生下

    列错误:

    发生了一个错误事件。EventID: 0x40000004

    生成时间: 02/19/2020   17:13:54

    事件字符串:

    Kerberos 客户端收到了来自服务器 hhad1$ 的 KRB_AP_ERR_MODIFIED 错误。

    使用的目标名称为 LDAP/add638e6-1fc9-4795-afdd-86addf535285._msdcs.hhycad.com。这

    表明目标服务器无法解密客户端提供的票证。如果不是在目标服务正在使用的帐户上注册目

    标服务器主体名称(SPN),则会出现该问题。请确保仅在服务器使用的帐户上注册目标 SPN

    。如果目标服务使用的目标服务帐户密码与 Kerberos 密钥发行中心上配置的密码不同,也

    会出现该问题。请确保服务器和 KDC 上的服务均配置为使用同一密码。如果服务器名称未

    完全限定,并且目标域(HHYCAD.COM)与客户端域(HHYCAD.COM)不同,则请检查这两个域中是

    否有相同名称的服务器帐户,或使用完全限定的名称标识服务器。

    发生了一个错误事件。EventID: 0x40000004

    生成时间: 02/19/2020   17:13:54

    事件字符串:

    Kerberos 客户端收到了来自服务器 hhad1$ 的 KRB_AP_ERR_MODIFIED 错误。

    使用的目标名称为 ldap/hhad1.hhycad.com。这表明目标服务器无法解密客户端提供的票证

    。如果不是在目标服务正在使用的帐户上注册目标服务器主体名称(SPN),则会出现该问题

    。请确保仅在服务器使用的帐户上注册目标 SPN。如果目标服务使用的目标服务帐户密码与

    Kerberos 密钥发行中心上配置的密码不同,也会出现该问题。请确保服务器和 KDC 上的

    服务均配置为使用同一密码。如果服务器名称未完全限定,并且目标域(HHYCAD.COM)与客户

    端域(HHYCAD.COM)不同,则请检查这两个域中是否有相同名称的服务器帐户,或使用完全限

    定的名称标识服务器。

    ......................... HHAD2 没有通过测试 SystemLog

    开始测试: VerifyReferences

    ......................... HHAD2 已通过测试 VerifyReferences

    正在 ForestDnsZones

    上运行分区测试

    开始测试: CheckSDRefDom

    ......................... ForestDnsZones 已通过测试 CheckSDRefDom

    开始测试: CrossRefValidation

    ......................... ForestDnsZones 已通过测试 CrossRefValidation

    正在 DomainDnsZones

    上运行分区测试

    开始测试: CheckSDRefDom

    ......................... DomainDnsZones 已通过测试 CheckSDRefDom

    开始测试: CrossRefValidation

    ......................... DomainDnsZones 已通过测试 CrossRefValidation

    正在 Schema

    上运行分区测试

    开始测试: CheckSDRefDom

    ......................... Schema 已通过测试 CheckSDRefDom

    开始测试: CrossRefValidation

    ......................... Schema 已通过测试 CrossRefValidation

    正在 Configuration

    上运行分区测试

    开始测试: CheckSDRefDom

    ......................... Configuration 已通过测试 CheckSDRefDom

    开始测试: CrossRefValidation

    ......................... Configuration 已通过测试 CrossRefValidation

    正在 hhycad

    上运行分区测试

    开始测试: CheckSDRefDom

    ......................... hhycad 已通过测试 CheckSDRefDom

    开始测试: CrossRefValidation

    ......................... hhycad 已通过测试 CrossRefValidation

    正在 hhycad.com

    上运行企业测试

    开始测试: LocatorCheck

    ......................... hhycad.com 已通过测试 LocatorCheck

    开始测试: Intersite

    ......................... hhycad.com 已通过测试 Intersite

    展开全文
  • 张戈博客很久之前分享过一篇WordPress发布文章同步到新浪微博的文章,但经常有站长留言反馈同步失败,我一直觉得是代码部署问题。最近很长一段时间,张戈博客也无法同步,我又觉得是微博自身的问题。直到近期抽空...
  • FlinkX数据同步

    2021-01-07 18:16:31
    Flink数据同步先行者-FlinkX 最近在学习Flink,看到目前的Connector支持还较少,联想之前的DataX与FlinkX,由感而发。 从我个人的理解上,Connector是连接各个数据源的连接器,它屏蔽了一系列的组件兼容问题,...
  • 然后,我有一个查询,该查询汇总了应用程序中的数据并将其拆分为更有用的格式.在我的MySQL数据库中,我有一个表,其中包含与上述查询输出相同的架构.我要开发的是每小时执行一次的cron作业,它将对PostgreSQL数据库运行...
  • 本发明涉及税务开票领域,更具体地,涉及一种基于金税盘控制系统登录和数据同步的方法。背景技术:在以往的增值税销方开票操作中,销方用户在执行开票操作时,往往会出现当前用户信息与所使用的金税盘信息不匹配的...
  • 核心银行系统|聊聊平台系统之ECIF 2021-04-02转自liang1234_ 火锅的发展亦如同银行系统的发展是渐进式的,完全是依据当时的器皿,社会的需求与原物料的发现引进,而加以变化的。它最早起源于战国时期,...
  • 比如从oracle数据库中同步一张表的数据到Mysql中,通常的做法就是 分页查询源端的表,然后通过 jdbc的batch 方式插入目标表,这个地方需要注意的是,分页查询时,一定要按照主键id来排序分页,避免重复插入。...
  • 为什么要同步SQL Server 2000 数据库,它都用在什么场合数据实时备份同步,数据库服务器出问题时我们也有其正常工作时的备份数据实时备份同步,一服务器负载不起时,可以用来做负载均衡数据实时备份同步,数据库...
  • 学习目标能够完成canal环境的搭建与数据监控微服务的开发能够完成首页广告缓存更新的功能,掌握OkHttpClient的基本使用方法能够完成商品上架索引库导入数据功能,能够画出流程图和说出实现思路能够完成商品下架索引...
  • 实验方案概述本实验是对RDS同步数据到MaxCompute的一个初步讲解。当企业需要利用MaxCompute进行数据开发时,如果数据不在MaxCompute而在RDS中,首先需要将RDS中的数据同步MaxCompute。本实验将以RDS(MySQL)为例,...
  • 我们已经观察了一系列不同的模式,试图解决多数据存储的同步问题,比如双写、分布式事务等等。然而,这些方法在可行性、健壮性和可维护方面有局限性。除了数据同步之外,一些应用程序还需要通过调用外部服
  • 5.1 数据抽取方式 5.1.1 基于源数据的CDC 5.1.2 基于触发器的CDC 5.1.3 基于快照的CDC 5.1.4 基于日志的CDC 5.2 MySQL数据复制 5.2.1 复制的用途 5.2.2 二进制日志 5.2.3 复制步骤 5.3 使用Kafka 5.3.1 ...
  • 编辑推荐:本文来自hahack,文章介绍如何利用Gitlab API 实现一套简单灵活的数据同步机制,从而实现在多个 Gitlab站点间同步数据。需求描述在继续写数学系列前,我想切回去之前的 Git 系列写点东西。我想写系列文章也...
  • Datax-数据抽取同步利器

    千次阅读 2020-12-19 19:55:18
    一 Datax概览DataX 是一个异构数据源离线同步工具,致力于实现包括关系型数据库(MySQL、Oracle等)、HDFS、Hive、ODPS、HBase、FTP等各种异构数据源之间稳定高效的数据同步功能。为了解决异构数据同步问题,DataX将...
  • 去哪儿数据同步平台主要是数据同步模块、数据( crab )和管理模块组成,整体架构如下图所示。 2.1 数据同步平台介绍 数据同步模块包括 databus 、 canal 、 inception gate 等多种实现方案,我们从同步配置易用性...
  • 数据同步用一个简单的模型可以描述为源端(Source)目标端(Sink)的数据复制过程。源端通常是数据库比如Mysql、目标端通常是分布式存储系统如HDFS等,在源端和目标端有时需要进行...
  • 数据同步工具MongoShake

    2021-03-24 16:20:29
    文章目录一、MongoShake1.1 ...  MongoShake是一个以go语言编写的通用的平台型服务,通过读取MongoDB集群的Oplog日志,对MongoDB的数据进行复制,后续通过操作日志实现特定需求。   MongoShake从源库抓取oplog数据
  • BDC无法正常与PDC同步,在BDC上手动从PDC同步,出现错误提示:目标服务器目前拒绝复制请求在BDC上执行dcdiag命令出现下面结果,希望各位大神帮忙看看:目录服务器诊断正在执行初始化设置:正在尝试查找主服务器......
  • 本文将介绍canal项目中client-adapter的使用,以及落地生产中需要考虑的可靠性、高可用...虽然阿里也开源了一个纯粹从mysql同步数据到mysql的项目otter(github.com/alibaba/otter,基于canal的),实现了mysql的单向...
  • 业务中台数据一致性方案

    千次阅读 多人点赞 2021-10-10 16:40:21
    如下图所示,业务中就是将平台的通用能力进行下沉,避免重复建设,形成底座平台能力,上层的各个应用服务都是基于中能力进行快速构建。但是随着应用规模的扩大,原本在单体应用中不是问题的问题,在微服务架构中...
  • 在线QQ客服:1922638专业的SQL Server、MySQL数据库同步软件前言定时任务在系统中并不少见,主要目的是用于需要定时处理数据或者执行某个操作的情况下,如定时关闭订单,或者定时备份。而常见的定时任务分为2种,第...
  • 3-STM32+ESP8266连接onenet上传数据+远程控制(MQTT)

    千次阅读 多人点赞 2021-06-11 11:30:11
    3-STM32+ESP8266连接onenet上传数据(MQTT) MQTT协议介绍–点我 开发流程–点我 素材获取请点我-提取码dz91 一、onnet云平台创建产品和设备 1、在控制台首页切换旧版本 控制台首页–请点我 2、选择全部产品-多协议...
  • CloudCanal是一款由ClouGence公司发行的集结构迁移、数据全量迁移/校验/订正、增量实时同步为一体的数据迁移同步平台。产品包含完整的产品化能力,助力企业打破数据孤岛、完成数据互融互通,从而更好的使用数据。...
  • 在线QQ客服:1922638专业的SQL Server、MySQL数据库同步软件这里实现方式事先说明下,采用json+文本流方式,即读取数据库信息至文本流中,格式采用json,之后读取文本中json数据至数据库中,实现度还不完全,不过也...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 134,494
精华内容 53,797
关键字:

同步数据到控制平台失败