250929-Java-Semaphore信号量多线程并发控制

多线程并发信号量控制逻辑

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
/**/
private static final ConcurrentHashMap<String, Long> LOCK_DTO_MAP = new ConcurrentHashMap<>();

private static final ConcurrentHashMap<String, Semaphore> SEMAPHORE_MAP =
    new ConcurrentHashMap<>();

private static final long TIMEOUT_DURATION = 60_000; // 60 seconds

public static boolean lock(String key) {
  Semaphore semaphore = SEMAPHORE_MAP.computeIfAbsent(key, k -> new Semaphore(1, true));
  boolean acquired = false;

  try {
    // 1. 拿到许可证
    acquired = semaphore.tryAcquire(1, TimeUnit.SECONDS);
    Preconditions.checkState(acquired, "获取锁超时: " + key);

    // 2. 现在互斥了，再操作被保护资源
    Long old = LOCK_DTO_MAP.putIfAbsent(key, System.currentTimeMillis());
    Preconditions.checkState(old == null, "Lock already held by this thread for key: " + key);

    return true;
  } catch (Exception ignored) {
  } finally {
    /* 4. 关键：只有真正拿到过许可的线程才需要“善后” */
    if (acquired) {
      /* 4.1 判断是否超时，超时就当“没发生过”直接删记录 */
      try {
        long holdTime = System.currentTimeMillis() - LOCK_DTO_MAP.get(key);
        if (holdTime > TIMEOUT_DURATION) {
          LOCK_DTO_MAP.remove(key); // 删记录" 超时，记录+许可证已清理"
        }
      } finally {
        semaphore.release(); // 还许可证
      }
    }
  }
  return false;
}

/** 清空StripedLockUtils的所有数据 */
public static void clearAppRestart() {
  for (String key : LOCK_DTO_MAP.keySet()) {
    StreamUtils.silentException(
        () -> {
          unlock(key);
          SEMAPHORE_MAP.remove(key);
        });
  }
}

public static void unlock(String key) {
  StreamUtils.silentException(() -> LOCK_DTO_MAP.remove(key));
}

250927-RPM查看安装软件和卸载软件(rpm -qa | grep mongodb-org)

  1. 确认已安装的 MongoDB 家族版本

    1
    rpm -qa | grep mongodb-org

典型输出：

1
2
3
4
5
mongodb-org-server-8.2.0-1.el8.x86_64
mongodb-org-shell-8.2.0-1.el8.x86_64
mongodb-org-tools-8.2.0-1.el8.x86_64
mongodb-org-mongos-8.2.0-1.el8.x86_64
mongodb-org-database-tools-extra-8.2.0-1.el8.x86_64

  1. 卸载

    1
    rpm -e mongodb-org-server-8.2.0-1.el8.x86_64

输出

1
2
Removed /etc/systemd/system/multi-user.target.wants/mongod.service.
warning: file /run/mongodb: remove failed: No such file or directory

250913-Shell工具Shell-MobaXterm重置主密码工具

mobaxterm密码忘记，如何重置密码？

解决方法： 使用MobaXterm主密码重置工具ResetMasterPassword，一键去除打开软件主密码。

官网 MobaXterm free Xserver and tabbed SSH client for Windows (mobatek.net)

https://mobaxterm.mobatek.net/

软件去掉密码 MobaXterm Xserver and tabbed SSH client - resetmasterpassword (mobatek.net)

ResetMasterPassword.zip

https://mobaxterm.mobatek.net/resetmasterpassword.html

250902-ubuntu20.04分辨率-只有一个800x600的分辨率怎么升级

在Ubuntu 20.04中，如果遇到分辨率只有800x600的情况，可以尝试以下方法来升级或调整分辨率：

更新软件

1
2
sudo apt update
sudo apt upgrade

配置GRUB

可以在/etc/default/grub文件中找到注释掉的GRUB_GFXMODE行，取消注释并设置为你的目标分辨率，例如GRUB_GFXMODE=1920x1080
，然后更新GRUB配置并重启

1
GRUB_GFXMODE=1920x1080

250901-MySQLImport导入数据-以确保字符集的一致性--default-character-set=utf8

–default-character-set=utf8

遇到 “ERROR at line 13404: Unknown command ‘’’” 错误时，这通常是由于字符集问题导致的。为了解决在 MySQL
导入数据时的问题，可以尝试以下几种方法：

  1. 指定字符集：在导入命令中添加 --default-character-set=utf8 参数，以确保字符集的一致性。例如：

    1
    mysql -u root -h 127.0.0.1 -P 33067 --default-character-set=utf8 mujitokyo_dev<mujitokyo_dev.sql

这样可以避免因字符集不匹配导致的数据导入失败

。

  1. 检查文件编码：确保 SQL 文件的编码格式与 MySQL 服务器的编码格式一致。可以使用文本编辑器或命令行工具（如 ）来转换文件编码。

  2. 使用特定编码导出：在导出数据库时，就使用特定编码的形式导出。例如，如果需要导入的数据库环境编码是utf8，那么在导出时就使用utf8格式。

  3. 调整命令行客户端编码：在命令行客户端连接服务器时指定编码，例如：

    1
    mysql -uroot -h192.168.0.1001 -p --default-character-set=utf8

这可以避免前面遇到的错误

。

  1. 修改 max_allowed_packet 设置：如果导入的 SQL 文件较大，可能需要调整 MySQL 的 max_allowed_packet 设置，以允许更大的数据包传输

250901-MySQL--skip-grant-tables跳过权限表-处理数据库异常恢复数据

你可以将 --skip-grant-tables 选项添加到 MySQL 的配置文件中，以便在每次启动时自动应用此设置。然而，需要注意的是，
--skip-grant-tables 选项会跳过权限表的加载，这意味着所有用户都可以无需密码登录到 MySQL
服务器，这会带来重大的安全风险。因此，通常只在进行特定维护任务时临时使用此选项。

将 --skip-grant-tables 添加到配置文件

  1. 找到 MySQL 配置文件： MySQL 的配置文件通常名为 my.cnf 或 my.ini，位于 /etc/mysql/、/etc/mysql/mysql.conf.d/
    或 MySQL 安装目录下。

  2. 编辑配置文件： 打开配置文件，找到 [mysqld] 部分，并添加 --skip-grant-tables 选项。例如：

    1
    2
    [mysqld]
    skip-grant-tables

  3. 保存并关闭文件。

  4. 重启 MySQL 服务： 重启 MySQL 服务以应用更改：

    1
    sudo systemctl restart mysql

使用 --skip-grant-tables 的注意事项

  • 安全性：由于 --skip-grant-tables 会跳过权限检查，任何用户都可以无需密码登录到 MySQL
    服务器。因此，在使用此选项时，必须确保数据库服务器不对外部网络开放，或者在防火墙中严格限制访问权限。
  • 临时使用：通常只在需要修复权限表或进行其他需要跳过权限检查的维护任务时临时使用 --skip-grant-tables
    。完成这些任务后，应立即从配置文件中移除此选项，并重启 MySQL 服务。
  • 备份：在修改配置文件或进行任何可能影响数据库安全性的操作之前，确保备份所有重要数据。

从配置文件中移除 --skip-grant-tables

完成维护任务后，应立即从配置文件中移除 --skip-grant-tables 选项，并重启 MySQL 服务以恢复正常的权限检查：

250901-MySQL-LogFile-ib_logfile启动异常处理

异常信息

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
2025-09-01T01:38:07.723468Z 0 [ERROR] InnoDB: Ignoring the redo log due to missing MLOG_CHECKPOINT between the checkpoint 1108276937 and the end 1108281882.
2025-09-01T01:38:07.723499Z 0 [ERROR] InnoDB: Plugin initialization aborted with error Generic error
2025-09-01T01:38:08.332206Z 0 [ERROR] Plugin 'InnoDB' init function returned error.
2025-09-01T01:38:08.332263Z 0 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
2025-09-01T01:38:08.332280Z 0 [ERROR] Failed to initialize builtin plugins.
2025-09-01T01:38:08.332294Z 0 [ERROR] Aborting

2025-09-01T01:38:08.332312Z 0 [Note] Binlog end
2025-09-01T01:38:08.332392Z 0 [Note] Shutting down plugin 'CSV'
2025-09-01T01:38:08.334119Z 0 [Note] mysqld: Shutdown complete


2025-09-01T03:20:31.722426Z 0 [ERROR] InnoDB: Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB log files. Please refer to http://dev.mysql.com/doc/refman/5.7/en/forcing-innodb-recovery.html for information about forcing recovery.
2025-09-01T03:20:31.722543Z 0 [ERROR] InnoDB: Page [page id: space=0, page number=635] log sequence number 1041821149 is in the future! Current system log sequence number 1040642590.
2025-09-01T03:20:31.722583Z 0 [ERROR] InnoDB: Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB log files. Please refer to http://dev.mysql.com/doc/refman/5.7/en/forcing-innodb-recovery.html for information about forcing recovery.
2025-09-01T03:20:31.722683Z 0 [ERROR] InnoDB: Page [page id: space=0, page number=1371] log sequence number 1040709155 is in the future! Current system log sequence number 1040642590.

从你提供的日志来看，
MySQL 在启动时遇到了与 InnoDB 存储引擎相关的问题，导致无法正常启动。
以下是日志中显示的几个关键问题及其可能的原因：

1. InnoDB 忽略重做日志

1
2
3
2025-09-01T01:38:07.723468Z 0 [ERROR] 
              InnoDB: Ignoring the redo log due to missing MLOG_CHECKPOINT 
              between the checkpoint 1108276937 and the end 1108281882.
  • 问题描述：InnoDB 在启动时检查重做日志（redo log），发现缺少 MLOG_CHECKPOINT，导致无法正确恢复数据。
  • 可能原因：
    • 数据库在上次关闭时没有正常关闭，导致重做日志不完整。
    • 数据文件（如 ibdata1 或 ib_logfile*）可能被损坏或丢失。

2. 可以尝试删除的文件

**ib_logfile\***：这些是 InnoDB 的重做日志文件，用于恢复操作

在某些情况下，可以尝试删除一些临时文件或日志文件，但需要谨慎操作：

  • **ib_logfile\***：如果这些文件损坏，可以尝试删除它们，然后重新启动 MySQL。MySQL 会自动重新创建这些文件。但请注意，这可能会导致一些未提交的事务丢失。
  • **\*.err**：这是 MySQL 的错误日志文件，删除它不会影响数据库的运行，但建议先备份，以便后续查看错误信息。

250830-Mongodb清理磁盘空间碎片-db-runCommand-compact

问题描述

私服客户业务量的增加，录音数据不断增加，面临着磁盘空间不足的情况，因为 MongoDB 的特性，直接删除数据占用的磁盘空间并不会释放，即使
drop collection 也不行，除非 drop database。

如果一个 db 曾经有大量的数据一段时间后又删除的话，硬盘空间就是一个问题，如何收回被 mongodb 占用的多余空间？

磁盘空间越来越大，为了避免磁盘空间超过 95%以上导致锁库，清理方案迫在眉睫。

预估能整理的磁盘大小：

1
2
3
4
5
6
7
db
.call_audio
.chunks
.stats()
.wiredTiger["block-manager"]["file bytes available for reuse"] 

>>1795354353454byte (B)换算为TB后为1.63287TB

解决方法选型

SUCC-执行离线修复mongod –repair（指定数据目录和目标数据库）：

1
2
3
4
# 格式：mongod --repair --dbpath <数据存储目录> --repairDatabase <目标数据库名>
mongod --repair --dbpath /var/lib/mongodb --repairDatabase your_database_name

/var/lib/mongo

方法一：官方推荐 compact 整理（推荐指数 5 颗星）

img

操作步骤：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
0.连接MongoDB 节点1.use '业务DB' 
//切换到业务库2.查看预估可以整理的磁盘碎片大小
db
.call_audio.chunks
.stats()
.wiredTiger["block-manager"]["file bytes available for reuse"]

>>17953543534543.进行碎片整理

db.runCommand({compact:"<collection_name>",force:true});

db.runCommand({compact:"device_data",force:true});

说明：（<collection_name>：集合名。
您可以通过show tables命令查询现有的集合。
force为可选项，如您需要在副本集实例的Primary节点执行该命令，需要设置force的值为true。）

4.等待执行，返回{ "ok" : 1 }
代表执行完成。
说明：（如果您执行的目标是一个大集合，而compact命令马上就返回{ "ok" : 1 }集合的物理空间也没有任何变化，则表示该集合没有必要进行碎片整理。

compact操作不会传递给Secondary节点，当实例为副本集实例时，请重复上述步骤通过MongoDB shell连接至Secondary节点，执行碎片整理命令。）
5.验证磁盘空间有没有变化

在MongoDB中，db.runCommand({compact:"collectionName",force:true})
用于压缩指定集合的数据文件，释放未使用的空间。
如果在执行该命令时出现超时问题，
可以尝试以下几种方法来处理：

1. 增加超时时间

MongoDB允许你设置命令的超时时间。
你可以通过maxTimeMS选项来设置命令的最大执行时间（以毫秒为单位）。
例如：

1
2
3
4
5
db.runCommand({
  compact: "device_data",
  force: true,
  maxTimeMS: 3600000 // 设置超时时间为3600秒（1小时）
});

注意点：

1
2
3
4
5
当然以上是我们期望的多么完美的运行过程！！！
注意点：
	1.执行前一定要停掉业务系统，确保没有读写操作，否则会导致锁住
	2.大部分情况下磁盘慢场景下，都不满足磁盘整理的条件，所以操作后很快就返回了，如果删除了很多数据，并且还有不小于10%-20%剩余空间的话，还可以跑一下
	3.不要气馁，还有其他方法释放空间

方法二：secondary 节点同步（推荐指数 5 颗星）

主要思想就是：在有新机器（磁盘）的情况下，新建一个 secondary 节点，使之与 primary 节点开始数据同步。数据的同步与直接复制数据文件不同，MongoDB
会只同步数据，因此同步完成后的数据文件是没有空集合的，以此实现了磁盘空间的回收。

上步骤：

img

注意点：

1
2
3
4
5
6
7
8
注意点：    
1.一定要做好数据的备份。    
2.一定要注意主从配置优点：    
	1.同步的方法是比较好的，第一基本不会阻塞副本集的读写，    
	2.第二消耗的时间相对比较短，2T数据大概在74H内同步完成，且不影响正常使用。    
3.second会清理掉大量的磁盘空间，达到我们的目的    
4.索引会自动创建，不用再手动去创建缺点：    
	1.不用于复制包含分片集合的数据库

方法三：copyDatabase（推荐指数 3 颗星）

MongoDB 还支持在线复制数据：db.copyDatabase(“from”,”to”,”IP:port”),此种方法也能释放空间，因为 db.copyDatabase
复制的数据，而不是表示在磁盘中的数据文件。但是该方法在 4.0 版本起被弃用，3.x
版本还能继续使用，还可以复制远端数据库哦，方便多节点复制操作，但是需要我们备份好主库索引，手动创建索引。

主流程：

1
2
3
0.停掉所有业务数据读写操作1.db.copyDatabase("from","to","127.0.0.1:16161");复制出一个新的to数据库。这个已经是最小数据占用的数据。会在数据目录下产生to的相关数据文件。
2.将所有程序的配置从from库改为to库。测试无误。
3.这时可以删除from库。方法。use from 后 db.dropDatabase()。这个方法的好处是可以时间将磁盘上的数据删除掉，节省出很大的空间，但是需要手动创建索引。

上方法：

1
前提停掉所有服务0.Primary 对要迁移的db进行授权use 业务DB;db.createUser( { user: "rcrai", pwd: "xxxx", roles: [ "readWrite", "dbAdmin" ] } )db.grantRolesToUser('rcrai',[{ role: "dbAdmin", db: "业务DB" }]) 1.second机器上执行copy操作db.copyDatabase("源业务DB", "目标业务DB", "10.10.10.26:30017","rcrai","xxxx");2.等待执行完成，执行创建索引

注意点：

1
注意：second copy没执行完成和second索引没有手动创建完成前，一定不要启动业务读写，copy操作比较消耗IO，容易干挂docker的网络环境优点：    1.纯copy数据方式，速度快 2T数据耗时15小时完成    2.支持远程复制    3.second会清理掉大量的磁盘空间缺点：    1.不能自动创建索引    2.MongoDB4.0不支持，推荐方法三    3.不用于复制包含分片集合的数据库

方法四：mongodump And mongorestore（推荐指数 2 颗星）

原理简单粗暴，停服务，dump 出来数据，再 restore 回去。

上方法：

1
1.停业务服务，停止业务数据读写2.执行dump数据操作mongodump --host 10.10.12.25 --port 30017 -u rcrai -p eawmzaxtfnptvtpxefkd --authenticationDatabase admin --oplog -o /data/dumpmongo/3.执行restore恢复mongorestore --host 10.10.12.26 --port 30018 -u rcrai -p eawmzaxtfnptvtpxefkd --authenticationDatabase admin --oplogReplay /data/dumpmongo

注意点：

1
优点：    1.操作简单，步骤少    2.只适用于小量数据（小于200G的场景）缺点：    1.如果数据量比较大（大于200G），mongorestore执行时间较长（3T数据恢复大于100H）

方法五：db.repairDatabase()（推荐指数 1 颗星）

官网该命令的定义：清理无效或损坏的数据并重建数据库索引。类似于文件系统修复命令
fsck,所以此命令主要是用于修复数据。但是需要停机业务服务，即便你不停业务服务读写的话 MongoDB 自己也会锁住直到 repair
完成。注意要有足够的磁盘空间，需要额外一倍的空间，如果 MongoDB 占用了 500G，那么 repair 时还需要额外的 500G+2G 空间。

上方法：

1
use 业务DB;db.repairDatabase();

注意点：

1
注意：    1.db.repairDatabase()主要用于修复数据。若你拥有数据的完整副本，且有权限访问，请使用第二种方法“secondary节点同步”    2.在执行命令前请保证你有比较新的备份    3.此命令会完全阻塞数据库的读写，谨慎操作    4.此命令执行需要数据文件所在位置有等同于所有数据文件大小总和的空闲空间再加上2G    5.在使用MMAPv1存储引擎的secondary节点上执行该命令可以压缩集合数据    6.在使用WiredTiger存储引擎的MongoDB库上执行不会有压缩的效果    7.再碰到特殊情况要停止运行该命令时，可通过db.currentOp()查询进程信息，然后通过db.killOp()干掉进程优点：    1.可以追加磁盘，然后将目标目录指向新加的磁盘缺点：    1.非常消耗时间    2.在生产上操作如果意外停止可能会造成数据无法恢复的危险。    3.如果磁盘空间不足，小于现在这个db占用的空间，这种情况是用不了

总结

最终我们采用的是第二种和第三种方法去做的磁盘清理方案，操作客户的数据最终还是要从时效性，稳定性，以及失败的可恢复性去考虑。大家一定要注意：1.客户数据基本都在
T
级别以上，操作大规模数据属于高危操作，每一步都要慎重，且每一个环节和步骤都要在测试环节做大数据量的测试操作。2.一定要有至少一份的备份数据，且一段时间（一周）内不能被清除。3.方案不止要准备一种，私服环境多样，根据实际情况选择合适的方案。

【注】通过对官网的文档查阅不难发现，

MongoDB删除集合数据，物理磁盘空间不会直接释放，即使drop collections也无济于事。
除非drop databases。
在MongoDB4.0及以下，官网提供了一种回收MongoDB磁盘空间的方法，即 db.repairDatabase()，但该操作有一定的风险性。
注意MongoDB4.0以上版本 db.repairDatabase()方法已经被废弃。

【注】4.2 修复数据库repairDatabase()

db.repairDatabase()操作需要停业务进行，因为MongoDB会锁库直到 repair 操作完成。
另外，必须注意预留足够的磁盘空间，需要额外一倍的空间，如果MongoDB 占用数据磁盘了100G，那么 repair 时还需要额外的100G+2G 空间。
也可以追加磁盘，然后将目标目录指向新加的磁盘。

【注】.选择压缩率更高的算法

MongoDB 默认的建表方式采用 snappy 压缩算法。如果有需要，可以采用压缩率更高的 zlib 和 zstd 算法。
我曾经在某些业务中使用 zlib 算法，相比 snappy 能再节省 50% 的存储空间，仅供参考。

1
db.runCommand({create:<collection name>, storageEngine: {wiredTiger: {configString: "block_compressor=zlib"}}})

【注】.避免索引占用太多空间

可以在 mongo shell 终端执行 db.collection.stats() 查看索引大小。如果索引大小过大，需要进行优化：

通过 indexStats
命令查看索引使用情况，对于不会使用的索引，可以考虑删除。
参考：https://www.mongodb.com/docs/v6.0/reference/operator/aggregation/indexStats/
索引包含的字段应该尽量精简；
对于大 value 字段，可以在业务允许的场景下考虑使用 Hash 索引。参考下面的测试，可以将索引的大小降低 1 个数量级;

1
2
3
4
5
使用 YCSB 插入约 260 万条数据，对其中一个字段建索引，该字段为 100B 大小的BinData.
发现 Hash 索引比普通索引的存储空间降低了一个数量级:
Hash 索引 49MB VS 普通索引 310MB.
"field0_1" : 310861824,
"field0_hashed" : 49340416

250830-Mongodb清理磁盘空间碎片(repairDatabase&&Compact)

mongodb collection 如何能实现自动清理磁盘空间

MongoDB本身没有提供直接的自动清理磁盘空间的功能，但可以通过以下几种方法来实现磁盘空间的清理

：

1. 使用compact命令

compact命令可以对集合进行碎片整理，回收空闲的物理空间。执行该命令后，MongoDB会重新组织集合的数据文件，释放未使用的空间。例如：

1
db.runCommand({compact: "collectionName"});

**1. 增加超时时间 **

MongoDB允许你设置命令的超时时间。
你可以通过maxTimeMS选项来设置命令的最大执行时间（以毫秒为单位）。
例如：

1
2
3
4
5
db.runCommand({
  compact: "device_data",
  force: true,
  maxTimeMS: 3600000 // 设置超时时间为3600秒（1小时）
});

。

2. 使用repairDatabase命令

repairDatabase命令可以修复数据库并回收磁盘空间。该命令会扫描数据库中的所有集合，删除无效的数据文件，并重新组织数据。执行方法如下：

1
db.repairDatabase();
1
db.runCommand({repairDatabase: 1});

此方法虽然有效，但可能会对数据库性能产生较大影响，且在执行过程中会锁定数据库

。

3. 基于时间的自动清理

如果需要定期清理旧数据以释放磁盘空间，可以使用MongoDB的TTL（Time To Live）索引。例如，为某个集合的日期字段创建TTL索引，设置过期时间为7天：

JavaScript

复制

1
db.collection.createIndex({createdAt: 1}, {expireAfterSeconds: 604800});

这样，MongoDB会自动删除createdAt字段值早于7天的文档。