九师兄

这个错误表明在 PostgreSQL 复制和 Write-Ahead Logging（WAL）机制的上下文中出现了问题。看起来是在 Debezium PostgreSQL 连接器的使用过程中发生的。WAL 段是 PostgreSQL 复制机制的关键部分，用于跟踪对数据库的更改。在应用任何更改到生产系统之前，请在非生产环境中进行充分的测试。此外，请查阅 PostgreSQL 和 Debezium 的文档以获取更详细的信息和故障排除指南。

这段代码的主要目的是在内存使用超过阈值时生成警告消息，以提醒用户可能存在内存问题，特别是对网络吞吐量的影响。警告消息提供了一些建议，例如增加可用网络内存或减小网络缓冲池的配置大小。

有个现场的hadoop有问题，然后他们重建了Hadoop集群，但是flink运行一段时间就报错，主要报错ApplicationMaster is out of sync with ResourceManager, hence resyncing。这里看起来是Hadoop不稳定，然后ResourceManager不停的在切换主备状态，导致程序无法连接。故障转移尝试次数很高（例如，5278 次尝试），这表明系统无法与 ResourceManager 建立稳定连接。

但是这个异常又不影响程序运行。但是这个有什么影响呢？下面我来解释一下，这个是flink认证相关的，他说/tmp/jaas-3331740396007956723.conf 这个文件中不包含一个叫Client的配置。如果有的话，那么就会走认证相关的配置。如果你的环境没有开启kerbeos认证的话，那么是没有什么问题的。

这里按理说应该是返回我们的403，而且debug的时候，应该走到我们抛出AcessDeniedException异常的地方，但是实际上什么都没有调用，看起来没有到后端就被拦截了，跨域什么的。然后与前端约定，当出现这个异常的时候，我们把状态码改成403，然后前端发现是403的时候，统一跳转到登录界面。首先用户登录系统，然后查看数据，接口正常情况下，我们返回的是200状态码。然后这里触发了我，因为我是强制删除了缓存信息，是不是证书也被清理了呢？过了很久，都没有找到原因，而且界面看起来是跨域相关的报错。

每次出现这种错误，需要人工干预手动重启jobmanager才能解决，不然任务就不运行了。这个错误日志表明 Flink TaskManager 在向 ResourceManager 注册时超时，导致 TaskManager 被终止。具体来说，错误信息是，指示在规定的最大注册持续时间内无法在 ResourceManager 上完成注册。确保 TaskManager 能够与 ResourceManager 正常通信。检查网络配置，确保没有防火墙或其他网络问题导致通信中断。

一个K8S上部署的flink集群的问题，taskmanager运行一段时间pod就会error，报错日志是然后jobmanager中没有报错，只是有拒绝的提示这个报错也是Flink TaskManager 在向 ResourceManager 注册中间发生的错误。我前面刚刚排查了一个问题。

现在 Flink 中 Checkpoint 有两种模式，全量 Checkpoint 和增量 Checkpoint，其中全量 Checkpoint 会把当前的state 全部备份一次到持久化存储，而增量Checkpoint，则只备份上一次Checkpoint 中不存在的state，因此增量 Checkpoint 每次上传的内容会相对更好，在速度上会有更大的优势。对于 RocksDB 来说，则需要从本地读取文件，写入到远程的持久化存储上，所以不仅需要考虑网络的瓶颈，还需要考虑本地磁密的性能。

1. 细粒度滑动的影响当使用细粒度的滑动窗口 (窗口长度远远大于滑动步长）时，重叠的窗口过多，一个数据会属于多个窗口，性能会急剧下降。比如我们开了一天的窗口，滑动时间是1分钟，那么数据会有多少次重复呢？重复次数的计算是长度/ 步长。而且flink是每次回计算这个数据属于某个窗口，如果这个数据属于多个窗口中，那么这个数据会被放到多个状态中。在Spark中是有这样的优化的，比如如上图的重复，那么A窗口会正常计算，但是B窗口的计算是重叠的部分是会重复利用的。但是Flink目前没有办法做这个优化。

对对于实时的流式处理系统来说，我们需要关注数据输入、计算和输出的及时性，所以处理延迟是一个比较重要的监控指标，特别是在数据量大或者软硬件条件不佳的环境下。Flink提供了开箱即用的 LatencyMarker 机制来测量链路延迟。single：每个算子单独统计延迟；这个就是统计一个算子的验证，比如从A进入到A出去，这个一般没有多大意义。operator（默认值）：每个下游算子都统计自己与 Source 算子之间的延迟;相当于全局延迟，是比较有用的。subtask。

默认情况下，算子UID 是根据JobGraph 自动生成的，JobGraph 的更改可能会导致UUID 改变，手动指定算子UUID，可以让Flink 有效地将算子的状态从 savepoint 映射到作业修改后(拓扑图可能也有改变）的正确的算子上。严格地说，仅需要给有状态的算子设置就足的了。但是因为 Flink 的某些内置算子（如window）是有状态的，而有些是无状态的，可能用户不是很清楚哪些内置算子是有状态的，哪些不是所以从实践经验上来说，我们建议每个算子都指定上 UUID。

【Flink】Flink RocksDB 预定义优化合集。

RocksDB的参数有几百个，如果是没有一定基础的想做这个优化还是很难的，因此flink提供了一些预定义的配置合集，并且每个合集有固定的名称。Flink 针对不同的设置为 RocksDB 提供了一些预定义的选项集合,其中包含了后续提到的一些参数，如果调整预定义选项后还达不到预期，再去调整后面的 block、writebuffer等参数。

Flink 1.13 State 访问的性能监控，即latency trackig state。此功能不局限于 State Backend 的类型，自定义实现的 State Backend 也可以复用此功能。正常开启第一个参数即可。

这个跟上个问题一样，并没有统一的设置，要看实际情况自行设置。

那么按照我们现在的情况，我们一个taskmanager有2个槽位，那么应该是需要2个vcore。其实这是调度器引起的问题，我们要么使用容量调度器，要么使用公平调度器，如果你使用的是公平调度器那么应该不会遇到这个问题。然后现在就变成了4和10了，现在我们算一算这个怎么来的，3个TaskManager，每个占用3个，那么就是9个，然后JobManager是一个。我并行度是5，那么最少占用5个槽位才能跑，一个taskmanager是2个槽位，那么最少要启动3个taskmanager才能满足我们的需求。

距离上一次搞内存已经很久了，今天打算再次学一下。Flink 1.10对 Task Manager 内存模型做了较大改动Flink使用了堆上内存和堆外内存框架堆外内存、Task堆外内存、网络缓冲内存，都在堆外的直接内存里Flink使用内存=框架堆内和堆外内存+Task堆内和堆外内存 ＋网络缓冲内存＋管理内存逃程内存=Flink内存+JVM特有内存首先要知道一点就是FLink是既能使用堆内存、又能使用堆外内存的。

在Flink 当中有两种基本类型的State : Keyed State 和 Operator State。Keyed State：顾名思义就是基于 KeyedStream 上的状态，这个状态是跟特定的key 鄉定的，对 KeyedStream 流上的每一个key，都对应一个 state。如下图所示：假如输入流按照 id 为key 进行 keyBy 分组，形成一个 KeyedStream，数据流中所有id 为1的数据共享一个状态，可以访问和更新这个状态。以此类推，每个key 对应一个自己的状态。

今天有空来学习一下，可查询状态 Queryable State。在flink 当中．state 分为两种类型，keyed state 和 operator state。keyed state 是与特定的key 绑定的state。对keyedStream 流上的每一个key， 都对应一个 state;operator state 是与算子绑定的 state，整个operator 算子只对应一个 state。

其中， 是作业的 JobID，可以在 Flink 的 Web UI 或者日志中找到， 是 Savepoint 保存的目录。当执行 Flink 的 stop 命令并指定 --savepointPath 参数时，如果操作超时，可能是由于不同原因导致的。8.检查 Flink 的日志，特别是 JobManager 和 TaskManager 的日志，以查看是否有任何与 Savepoint 相关的错误或警告消息。有时，不同版本之间的兼容性问题可能导致异常。

flink on k8s吗，我在kubernetes application模式下运行，运行一段时间后就会出现这个报错，然后jobmanager就重启了。2、确保你的操作是基于最新版本的 ConfigMap 进行的，可以使用 kubectl get configmap 命令查看当前版本。这是一个 Kubernetes 的错误消息，意思是在进行 ConfigMap 操作时发生了锁定问题和版本冲突。4、对于持久性锁定问题，可以通过更新或重新部署相关的应用程序来解决。

一个环境flink读取kafka不消费数据或者偶然消费数据、消费组信息查不到。在数据源节点查看节点每秒消费速率为0，意味着没有消费数据查看topic内部topic都正常，下图为部分查看我们消费的目标topic也是正常的查看消费组信息最后一行为nuknow，这是我们自定义的，意思是查不到查看日志发现无报错信息给这个流新换一个消费组，因为不消费所以没有初始化消费组信息，我们也查不到但是后来不知道什么原因，偶然能消费数据了。

但是现场不知道哪个傻叉，配置了一个最简单的规则，然后导致所有的数据都产生告警了，然后当所有数据都是告警，然后这个流我们配置的消费能力不高，然后每秒产生了几十万的告警，那么查询的时候就发现时间一直没有变化，因为一秒内的数据都要好久才能消费完。这个延迟达到了几十亿，卧槽，最终破案了，原来我们这个是读取日志，然后分析日志，产生告警然后写入到Es,一般情况下，这个消费的数据多，然后生成的数据少，所以我们没有怀疑是延迟问题。因为我们已经是12月14日了，但是今天来查数据的时候，发现最新的数据还是16：48。

请注意，在生产环境中，你需要确保目标 Socket 服务器能够接收并处理来自 SocketClientSink 的数据，并根据需要进行相关的配置和验证。SocketClientSink 是 Flink 的一个输出连接器（sink），可以将数据发送到一个指定的 Socket 地址和端口。你将看到数据被发送到指定的 Socket 地址和端口，并在 Socket 服务器上接收到这些数据。在上面的示例中，我们创建了一个简单的数据流，并将数据发送到指定的 Socket 地址和端口。

flink 消费kafka,之前任务正常的，突然有个分区没法消费了，重启下任务久正常了。

这个的含义是：回滚到检查点/保存点的元数据失败。检查点/保存点状态与新程序之间的最大并行度不匹配。无法将最大并行度为32768的运算符58212cb79e8186067bdc9ae3681ec630映射到最大并行度为1的新程序。这表明在检查点之后以不兼容的方式更改了程序。最后问题发现：代码变更太多 不能读历史的保存点启动了。

我们有个现场，然后最近总是无缘无故不消费数据，看起来像是卡死了一样，但是日志里面有找不到报错，关键是刚刚启动任务是能消费的数据的，比如消费一段时间后，10分钟差不多的样子（大概消费了几十万数据），就开始无法消费数据了，我们修改消费组后，可以再次消费一段时间。后面经了解，由于kafka磁盘目录存储已满，故对kafka日志进行了清理，清理时使用命令对日志进行了清空操作。经我方研发运维测试发现，”echo”命令直接清理日志会导致任务启动失败。

本次也是这个环境，昨天还能运行，今天升级一下就不能运行了，报错如下本次原因是flink-dist版本冲突，版本使用的还是老的版本导致的。“Flink 启动报错 NoSuchFieldError EXECUTION_MODE” 这个错误通常表示您的 Flink 应用程序代码与您正在使用的 Flink 版本之间存在不兼容性。EXECUTION_MODE 是 Flink 中的一个字段，该字段可能在不同的 Flink 版本中发生了变化，导致了这个错误。

如果需要补充缺失的变更前事件，一个自然的思路是在 Flink 状态中缓存所有文档的当前版本快照；不过 Flink 框架会自动为 MongoDB 附加一个 Changelog Normalize 节点，补齐 update 事件的前镜像值（即 UPDATE_BEFORE 事件)，从而确保 CDC 数据的语义正确性。目前，Flink SQL Planner 会自动为 Upsert 类型的 Source 生成一个 ChangelogNormalize 节点，并按照上述操作将其转换为完整的变更流；

但是在默认的情况下，FlinkKafkaProducer011设置事务超时属性(transaction.timeout.ms)为1 hour, 超过默认transaction.max.timeout.ms15 minutes。因此在使用EXACTLY_ONCE语义的时候需要增大transaction.max.timeout.ms或者减小任务的transaction.timeout.ms的值。生产者设置事务超时不允许大于这个值，这个属性不允许为大于其值的。对应的kafka代码位置。

场景：flink checkpoint的时候报错，导致checkpoint失败，并报如下错误原因：由于flink写hdfs会导致很多小文件，尝试小文件合并的时候，误将正在写的小文件合并掉了。因此，flink将inprogress文件转为finished文件时，找不到原来的文件报错，导致checkpoint失败。解决：合并小文件时注意，正在写的小文件不能合并。

我们最近在做一个FLink程序的全链路排查，核心思想就是实际运行的时候，实时的讲KafkaSource和kafkaSink替换成fromCollection和空输出，主要是测试中间算子。查看FromElementsFunction的序列化器，可以看到可以从构造方法传入或者从setOutputType构造。调试的时候发现走的是setOutputType，那么我们也走这个，然后我们自定义FromElementsFunction。因为我们实际有500个字段，非常不容易排查问题，如果能自动提示那么就好了。

对应的代码如下详情报错如下这个报错位于这里，使用你的数据进行推断TypeInformation，但是却发现无法推断无法推断的错误位置位于getField，但是我的fieldByPosition为空所以报错Flink Could not create TypeInformation for Type class Row please specify the TypeInformation manually via 错误信息解析如下。

根据源码可以知道报错位置位于requestNewBufferBuilderFromPool,看起来是在申请资源，然后反压，然后资源不足导致的问题。flink 1.13消费kafka报错：Interrupted while waiting for buffer。也可能是进行资源申请的时候，然后任务出现致命异常，然后主动让所有线程都。requestBufferBuilderBlocking是阻塞方法。然后是资源申请的地方。下面会死循环申请资源。

本篇博客是在上一篇博客：【Flink】FLink session yarn kerberos认证报错 KrbException: Cannot locate default realm还没找到原因的时候做的一次尝试。因为项目需要，我们需要对接华为认证的yarn集群，运行flink任务，我们的任务分为两种，yarn pre-job模式和flink session模式。我们在配置文件中配置如下# kerberos认证需要的东西提交任务的脚本如下。

在 Flink 中，Kafka 消费者的配置是通过 Flink Kafka Consumer 的属性进行的。具体来说，你可以在 Properties 中设置 Kafka 消费者的属性，以便在 Flink 作业中使用。如果你想在 Flink 消费 Kafka 数据时禁用自动解压缩，你可以通过配置 Kafka 消费者的参数来实现。在上面的示例中，关键是设置了 auto.decompress 属性为 false，这样就禁用了 Kafka 消费者的自动解压缩功能。确保你的处理逻辑能够正确处理数据的压缩格式。

flink启动任务，taskmanager.out 文件增涨非常快，这个文件大小怎么限定？测试了很多办法发现都不起作用。但是后面我发现不是这个导致的是slf4j依赖冲突，jar包删除就可以了。

flink metric 如何获取yarn applicationId。

flink 消费kafka数据，idea能正常消费，但是提交flink的jar包运行还是报这个错。（这是flink webui界面的logs提示）这个报错原因是因为没有资源了。解决方案：显示写入文件时无法满足hdfs要求的最小副本数，datanode节点故障或者不可写入导致su hdfst # 查看hdfs报告，查看对应datanode节点是否都live# 如果存在异常需要到对应datanode节点查看datanode的详细日志进行处理。

场景：消费kafka写入hdfs时，要从spark任务迁移为flink任务消费，为保证不丢数据，用同一个groupid消费数据flink消费数据，提交不了offset到kafka，报错如下原因：kafka的消费模式分为此种场景会发生standalone consumer（assign()消费模式）与consumer group冲突。