Shulou(Shulou.com)06/03 Report--

Redis-full-check verifies whether the redis data is consistent:

Verify 2 different redis instance data:

6986 is redis instance 1

6987 is redis instance 2

Log in to 6986 redis instance 1 and set 4 key values by simulation

[root@localhost redis-full-check-1.4.7] # redis-cli-h 127.0.0.1-p 6986-a 'Y2hJKSGtuEq'Warning: Using a password with'-a 'option on the command line interface may not be safe.127.0.0.1:6986 > keys * (empty list or set) 127.0.0.1 Using a password with 6986 > set test001 001OK127.0.0.1:6986 > set test002 002OK127.0.0.1:6986 > set test003 003OK127.0.0.1:6986 > set test004 004OK127 .0.0.1: 6986 > keys * 1) "test003" 2) "test002" 3) "test004" 4) "test001" 127.0.1

Log in to 6987 redis instance 2 and set 2 key values by simulation

[root@localhost redis-full-check-1.4.7] # redis-cli-h 127.0.0.1-p 6987-a 'Y2hJKSGtuEq'Warning: Using a password with'-a 'option on the command line interface may not be safe.127.0.0.1:6987 > keys * (empty list or set) 127.0.0.1 Using a password with 6987 > set test002 a02OK127.0.0.1:6987 > set test004 a04OK127.0.0.1:6987 > keys * 1) "test004" 2) "test002" 127.0.0.1 Using a password with 6987 >

The-m parameter specifies the verification mode, which can be divided into four types:

-m parameter comparison mode. 1 indicates full comparison, 2 indicates only the length of value, 3 only compares the existence of key, and 4 ignores the comparison of large key in the case of full comparison.

In terms of key name, key in 6987 instance is a subset of 6986 instance key:

If you do not specify a check mode, the default is-m 3 to only compare the existence of key. It is recommended that the full comparison mode of-m 1 should be adopted when verifying different redis instance data.

Verify the 6987 instance as the original instance and the 6986 instance as the target instance:

[root@localhost redis-full-check-1.4.7] # redis-full-check- s 127.0.0.1 result=result 6987-p 'Y2hJKSGtuEq'- t 127.0.0.1 log=log-a 'Y2hJKSGtuEq'--log=log-- JKSGtuEq'--result=result [JKSGtuEq] # lslog redis-full-check result result.db.1 result.db.2 result.db.3 [root@localhost redis-full-check-1.4.7] # sqlite3 result.db.3 SQLite version 3.7.17 2013-05-20 00:56:22Enter ".help" for instructionsEnter SQL statements terminated with a " "sqlite > select * from key;sqlite > select * from field;sqlite >

From the perspective of key name, since key in 6987 instance is a subset of 6986 instance key, there is no difference

At the same time, you can also see from the log:

[INFO 2020-02-08-12:29:32 main.go:65]: init log success [INFO 2020-02-08-12:29:32 main.go:164]: configuration: {127.0.0.1 INFO 6987 Y2hJKSGtuEq auth 0-1 127.0.1 log false 6986 Y2hJKSGtuEq auth 0-1 result.db result 32 unknown unknown unknown 15000 5 256 5 log false 16384 20445 false} [INFO 2020-02-08-12:29:32 main.go:166]:- -[INFO 2020-02-08-12:29:32 full_check.go:238]: sourceDbType=0 P.sourcePhysicalDBListist = [meaningless] [INFO 2020-02-08-12:29:32 full_check.go:243]: db=0:keys=2 [INFO 2020-02-08-12:29:32 full_check.go:253]:-start 1th time compare [INFO 2020-02-08-12:29:32 full_check.go:278]: start compare db 0 [INFO 2020-02-08-12:29:32 scan.go:20]: Build connection [source redis addr: [127.0.0.1 INFO 6987] [INFO 2020-02-08-12:29:33 full_check.go:203]: stat:times:1 Db:0, dbkeys:2, finish:33% Finished:trueKeyScan: {2 20} [INFO 2020-02-08-12:29:33 full_check.go:250]: wait 5 seconds before start [INFO 2020-02-08-12:29:38 full_check.go:253]:-start 2th time compare [INFO 2020-02-08-12:29:38 full_check.go:278]: start compare db 0 [INFO 2020-02-08-12:29:38 full_ Check.go:203]: stat:times:2 Db:0 Finished:trueKeyScan: {2020} [INFO 2020-02-08-12:29:38 full_check.go:250]: wait 5 seconds before start [INFO 2020-02-08-12:29:43 full_check.go:253]:-start 3th time compare [INFO 2020-02-08-12:29:43 full_check.go:278]: start compare db 0 [INFO 2020-02-08-12:29:43 full_ Check.go:203]: stat:times:3 Db:0, finished:trueKeyScan: {000} [INFO 2020-02-08-12:29:43 full_check.go:328]:-finished!-all finish successfully, totally 0 key (s) and 0 field (s) conflict

However, the original instance and the target instance are exchanged and compared, and the inconsistency is found.

Verify the 6986 instance as the original instance and the 6987 instance as the target instance:

Redis-full-check- 's 127.0.0.1 00:56:22Enter 6986-p 'Y2hJKSGtuEq'-t 127.0.0.1 Visu6987-a 'Y2hJKSGtuEq'-- log=log-- result=result [root@localhost redis-full-check-1.4.7] # sqlite3 result.db.3 SQLite version 3.7.17 2013-05-20 from key;1 ".help"; "sqlite > select * from field;sqlite > select * from key;1 | test001 | string | lack_target | 0 | 3 | 02 | test003 | lack_target | 0 | 3 | 0 | 0 |

It is seen that 6986 instances have 2 more key than 6987 instances.

You can also see the difference in the log:

[INFO 2020-02-08-12:35:10 main.go:65]: init log success [INFO 2020-02-08-12:35:10 main.go:164]: configuration: {127.0.0.1 log false 6986 Y2hJKSGtuEq auth 0-1 127.0.1 result.db result 3 2 unknown unknown unknown 15000 5 256 5 log false 16384 20445 false} [INFO 2020-02-08-12:35:10 main.go:166]:- -[INFO 2020-02-08-12:35:10 full_check.go:238]: sourceDbType=0 P.sourcePhysicalDBListist = [meaningless] [INFO 2020-02-08-12:35:10 full_check.go:243]: db=0:keys=4 [INFO 2020-02-08-12:35:10 full_check.go:253]:-start 1th time compare [INFO 2020-02-08-12:35:10 full_check.go:278]: start compare db 0 [INFO 2020-02-08-12:35:10 scan.go:20]: Build connection [source redis addr: [127.0.0.1 INFO 6986] [INFO 2020-02-08-12:35:11 full_check.go:203]: stat:times:1 Db:0, dbkeys:4, finish:33% Finished:trueKeyScan: {440} KeyConflictInProcess | string | lack_target | {220} [INFO 2020-02-08-12:35:11 full_check.go:250]: wait 5 seconds before start [INFO 2020-02-08-12:35:16 full_check.go:253]:-start 2th time compare [INFO 2020-02-08-12:35:16 full_check.go:278]: start compare db 0 [INFO 2020-02-08 -12:35:17 full_check.go:203]: stat:times:2 Db:0 Finished:trueKeyScan: {220} KeyConflictInProcess | string | lack_target | {220} [INFO 2020-02-08-12:35:17 full_check.go:250]: wait 5 seconds before start [INFO 2020-02-08-12:35:22 full_check.go:253]:-start 3th time compare [INFO 2020-02-08-12:35:22 full_check.go:278]: start compare db 0 [INFO 2020-02-08 -12:35:23 full_check.go:203]: stat:times:3 Db:0, finished:trueKeyScan: {220} KeyConflictAtLast | string | lack_target | {220} [INFO 2020-02-08-12:35:23 full_check.go:328]:-finished!-all finish successfully, totally 4 key (s) and 0 field (s) conflict

Value: field exists in source key and destination key, but the corresponding value of field is different.

Log in to the 6987redis instance and change key test004 to a04; modify key test003 A03

[root@localhost redis-full-check-1.4.7] # redis-cli-h 127.0.0.1-p 6987-a 'Y2hJKSGtuEq'Warning: Using a password with'-a 'option on the command line interface may not be safe.127.0.0.1:6987 > get test004 "A04" 127.0.0.1 Using a password with 6987 > get test002 "002" 127.0.0.1 Y2hJKSGtuEq'Warning 6987 > get test001 "001" 127.0.0.1 Y2hJKSGtuEq'Warning 6987 > get test003 "A03"

In this case, the full redis-full_check verification mode is adopted:

[root@localhost redis-full-check-1.4.7] # redis-full-check- s 127.0.0.1 log=log-p 'Y2hJKSGtuEq'-t 127.0.0.1 log=log-a 'Y2hJKSGtuEq'-- log=log-- result=result-M1 [root@localhost redis-full-check-1.4.7] # redis-full-check- s 127.0.0.1Viru 6987-p 'Y2hJKSGtuEq'-t 127.0.1JKSGtuEq'-t 12 -a 'Y2hJKSGtuEq'-- log=log-- result=result-m 4 [root@localhost redis-full-check-1.4.7] # redis-full-check- s 127.0.0.1-t 127.0.0.1 redis-full-check- 6987-a 'Y2hJKSGtuEq`-- JKSGtuEq1 [INFO 2020-02-08-14:44:36 main.go:65]: init log success. . [INFO 2020-02-08-14:44:49 full_check.go:328]:-finished!-all finish successfully Totally 4 key (s) and 0 field (s) conflict

There are data inconsistencies in 2 instances in the log.

It is found that the value values of key test003 and test004 in instance 6986 and 6987 are not the same:

[root@localhost redis-full-check-1.4.7] # sqlite3 result.db.3 SQLite version 3.7.17 2013-05-20 00:56:22Enter ".help" for instructionsEnter SQL statements terminated with a ";" sqlite > select * from key;1 | test004 | string | value | 0 | 3 | 32 | test003 | string | value | 0 | 3 | 3sqlite >

Log in to the 6987redis instance and delete key test001:

[root@localhost redis-full-check-1.4.7] # redis-cli-h 127.0.0.1-p 6987-a 'Y2hJKSGtuEq'Warning: Using a password with'-a 'option on the command line interface may not be safe.127.0.0.1:6987 > get test001 "001" 127.0.0.1 Using a password with 6987 > get test002 "002" 127.0.1 Y2hJKSGtuEq'Warning 6987 > get test003 "A03" 127.0.0.1 Using a password with 6987 > get test004 "A04" 127.0.0. 1Race 6987 > del test002 (integer) 1127.0.0.1 keys * 1) "test001" 2) "test004" 3) "test003"

In this case, the full redis-full_check verification mode is adopted:

[root@localhost redis-full-check-1.4.7] # redis-full-check- s 127.0.0.1 main.go:65 6986-p 'Y2hJKSGtuEq'- t 127.0.0.1 INFO 6987-a 'Y2hJKSGtuEq'--JKSGtuEq1 [JKSGtuEq1 [INFO 2020-02-08-14:54:25 JKSGtuEq']: init log success.. [ INFO 2020-02-08-14:54:38 full_check.go:328]:-finished!-all finish successfully Totally 6 key (s) and 0 field (s) conflict

It is found that there are inconsistencies in key and value values between instance 6986 and instance 6987:

[root@localhost redis-full-check-1.4.7] # sqlite3 result.db.3 SQLite version 3.7.17 2013-05-20 00:56:22Enter ".help" for instructionsEnter SQL statements terminated with a; "sqlite > select * from key;1 | test004 | string | value | 0 | 3 | 32 | test003 | string | value | 0 | 3 | 33 | test002 | string | lack_target | 0 | 3 | 0sqlite > select * from field

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.