無名
人生能有几回搏。
人生能有几回搏。
人生能有几回搏。
人生能有几回搏。
unclean.leader.election.enable：可配置是否允许不洁选举，慎用，会导致数据丢失（因为故障的磁盘可能数据是最新的）。
上周（最糟糕的一个星期五 ;-)）我们的 Nexus Repository Manager 服务发生了一起非常严重的事故，影响了我们产品的发布生命周期。不幸的是，我们的 NFS 服务器出现了问题，导致 Nexus Docker 出现以下几个损坏问题：
2019-09-05 19:38:17,321+0000 ERROR [FelixStartLevel] *SYSTEM com.orientechnologies.orient.core.storage.impl.local.paginated.OLocalPaginatedStorage - $ANSI{green {db=config}} Error on creating record in cluster: plocal cluster: quartz_trigger
com.orientechnologies.orient.core.exception.OPaginatedClusterException: Error during record creation
DB name="config"
Component Name="quartz_trigger"
at com.orientechnologies.orient.core.storage.impl.local.paginated.OPaginatedCluster.createSinglePageRecord(OPaginatedCluster.java:687)
at com.orientechnologies.orient.core.storage.impl.local.paginated.OPaginatedCluster.createDataRecord(OPaginatedCluster.java:564)
在搜索其他人如何解决这个问题时，大多数人都放弃了特定的定向数据库表：config.quartz_trigger。该表实际上是计划任务的持有者，因此删除并重新创建它并不是什么大问题。
连接到 orientdb 控制台。以下是连接 config db 并删除该表的命令：
java -jar /opt/sonatype/nexus/lib/support/nexus-orient-console.jar
connect plocal:/opt/sonatype/sonatype-work/nexus3/db/config/ admin admin
drop class quartz_trigger
然后修复数据库，断开连接并重新启动 Nexus。
REPAIR DATABASE component
DISCONNECT
“Low-Level Server”这个名字，源于软件开发中一个常见的术语：“low-level”（低层/底层）。它不是说“服务器很差”，而是强调它比高级封装更接近底层、原始的实现，意思是：
在 MCP 框架中，Low-Level Server 是一种更接近协议核心、需要你手动控制生命周期、注册处理函数的服务器写法，也就是说：
你负责：
call_tool()、list_prompts() 等）server.run()）它不像官方的 mcp run 或 mcp dev 那样封装好一整套流程（这些是 high-level 工具，自动帮你处理各种事情）。
和 “high-level”（高级封装） 相对：
uv run mcp runserver.run(...)，你控制 lifespan，你处理 stream就像 Python 的 asyncio：
asyncio.run(main())loop = asyncio.get_event_loop() 手动跑 loop用它是为了“更细粒度的控制”，适合这几种场景：
| 场景 | 为什么用 low-level server |
|---|---|
你想注册多个自定义 handler，比如 get_prompt、call_tool |
高级接口可能不够灵活 |
| 你想控制资源生命周期，比如连接数据库、清理缓存 | 需要用 lifespan |
| 你要接入自定义协议或更复杂的启动流程 | 高级封装不支持 |
你不想使用 mcp run 或 uv run |
这些不支持 low-level server |
“low-level server” 指的是一种更底层、自由度更高、但需要你自己处理细节的服务器写法。适合需要完全控制启动流程、资源管理、自定义能力的高级开发者。
“Low-Level Server”这个名字，源于软件开发中一个常见的术语：“low-level”（低层/底层）。它不是说“服务器很差”，而是强调它比高级封装更接近底层、原始的实现，意思是：
在 MCP 框架中，Low-Level Server 是一种更接近协议核心、需要你手动控制生命周期、注册处理函数的服务器写法，也就是说：
你负责：
call_tool()、list_prompts() 等）server.run()）它不像官方的 mcp run 或 mcp dev 那样封装好一整套流程（这些是 high-level 工具，自动帮你处理各种事情）。
和 “high-level”（高级封装） 相对：
uv run mcp runserver.run(...)，你控制 lifespan，你处理 stream就像 Python 的 asyncio：
asyncio.run(main())loop = asyncio.get_event_loop() 手动跑 loop用它是为了“更细粒度的控制”，适合这几种场景：
| 场景 | 为什么用 low-level server |
|---|---|
你想注册多个自定义 handler，比如 get_prompt、call_tool |
高级接口可能不够灵活 |
| 你想控制资源生命周期，比如连接数据库、清理缓存 | 需要用 lifespan |
| 你要接入自定义协议或更复杂的启动流程 | 高级封装不支持 |
你不想使用 mcp run 或 uv run |
这些不支持 low-level server |
“low-level server” 指的是一种更底层、自由度更高、但需要你自己处理细节的服务器写法。适合需要完全控制启动流程、资源管理、自定义能力的高级开发者。
我的意思是这个你不认识的地址，可能是从别的机器(192.168.66.211)连到kafka的时候，报的认证错误。
所以你先确认这个192.168.66.211的身份，是你公司的哪台机器属于谁的，可能是它一直连接kafka需要进行生产或者消费，而你加了认证之后，导致这台机器持续的连接重试，一直失败。
一般是docker的原因导致的。
一个可行的解决方案是重新启动 Docker 服务，然后重新运行 kubeadm reset：
sudo systemctl restart docker.service
sudo kubeadm reset
检查 docker 的日志：
journalctl -ul docker
你看下kafka集群的配置文件，是否设置了auto.create.topics.enable=false。
如果有，就设置为ture，当topic不存在，导致的，允许它自动创建。
或者你也可以手动创建topic：
bin/kafka-topics.sh --create --zookeeper localhost:2181 --replication-factor 2 --partitions 4 --topic test
$ kubectl wait --for=condition=complete --timeout=600s job/myjob
Kafka有5个核心API：
Producer API 允许应用程序发送数据流到kafka集群中的topic。Consumer API 允许应用程序从kafka集群的topic中读取数据流。Streams API 允许从输入topic转换数据流到输出topic。Connect API 通过实现连接器（connector），不断地从一些源系统或应用程序中拉取数据到kafka，或从kafka提交数据到宿系统（sink system）或应用程序。Admin API 用于管理和检查topic，broker和其他Kafka对象。具体可参考：kafka接口API
