Mysql 8.0 关闭binlog日志

Mysql8.0默认开启binlog记录功能,导致磁盘空间占用很大,8.0关闭的方式跟之前5.x的不太一样。

1.清除binlog文件

$ mysql -u root -p
#进入数据库查看log_bin状态
mysql> show variables like ‘log_bin';
+—————+——-+
| Variable_name | Value |
+—————+——-+
| log_bin | ON |
+—————+——-+
1 row in set (0.01 sec)

#查看现有在用的binlog日志
mysql> show master logs;
+—————+————+———–+
| Log_name | File_size | Encrypted |
+—————+————+———–+
| binlog.000020 | 1073742151 | No |
| binlog.000021 | 1073747018 | No |
| binlog.000022 | 1073930151 | No |
| binlog.000023 | 1073733807 | No |
+—————+————+———–+
4 rows in set (0.03 sec)

#手动清除binlog日志
mysql> reset master;
Query OK, 0 rows affected (0.02 sec)

#退出mysql
mysql> \q

2.关闭

#编辑配置文件/etc/my.cnf,添加disable_log_bin,有些版本可能是:skip-log-bin
$ vim /etc/my.cnf
[mysqld]
#
# Remove leading # and set to the amount of RAM for the most important data
# cache in MySQL. Start at 70% of total RAM for dedicated server, else 10%.
# innodb_buffer_pool_size = 128M
#
# Remove the leading “# ” to disable binary logging
# Binary logging captures changes between backups and is enabled by
# default. It’s default setting is log_bin=binlog
disable_log_bin
#skip-log-bin

#重启mysql服务
$ service mysqld restart

$ mysql -u root -p
#再次进入数据库查看log_bin状态
mysql> show variables like ‘log_bin';
+—————+——-+
| Variable_name | Value |
+—————+——-+
| log_bin | OFF |
+—————+——-+
1 row in set (0.01 sec)

#查看binlog日志报错提醒没有开启binlog
mysql> show master logs;
ERROR 1381 (HY000): You are not using binary logging

3.清理binlog

除了使用reset master清理日志文件之外,还可以按照日期清理:

purge master logs before ‘2024-01-18 00:00:00′;

ELK日志系统架构:Elasticsearch、Logstash、Kibana

ElasticSearch 安装

1、下载 ElasticSearch,本文使用的版本为 5.5.1。

2、配置

path.data: /data/es #数据路径
path.logs: /data/logs/es #日志路径
network.host: 本机地址 #服务器地址
http.port: 9200 #端口

如果不修改配置的话,默认的数据和日志都位于elasticsearch文件夹下。

默认地址会使用 192.168.0.1 的地址,此时ElasticSearch运行于开发模式,只能从本机访问。如果修改为生产地址,就会进入生产模式,并且运行 bootstrap check 。

3、启动

./bin/elasticsearch

注意,elasticsearch 不能使用 root 用户启动,使用其他用户启动,要注意有文件夹的读写权限。

我在安装过程中还出现了下面几个警告信息

[2017-08-07T09:13:59,951][WARN ][o.e.b.JNANatives         ] unable to install syscall filter: 
java.lang.UnsupportedOperationException: seccomp unavailable: requires kernel 3.5+ with CONFIG_SECCOMP and CONFIG_SECCOMP_FILTER compiled in
    at org.elasticsearch.bootstrap.SystemCallFilter.linuxImpl(SystemCallFilter.java:350) ~[elasticsearch-5.5.1.jar:5.5.1]
    at org.elasticsearch.bootstrap.SystemCallFilter.init(SystemCallFilter.java:638) ~[elasticsearch-5.5.1.jar:5.5.1]
    at org.elasticsearch.bootstrap.JNANatives.tryInstallSystemCallFilter(JNANatives.java:245) [elasticsearch-5.5.1.jar:5.5.1]
    at org.elasticsearch.bootstrap.Natives.tryInstallSystemCallFilter(Natives.java:113) [elasticsearch-5.5.1.jar:5.5.1]
    at org.elasticsearch.bootstrap.Bootstrap.initializeNatives(Bootstrap.java:111) [elasticsearch-5.5.1.jar:5.5.1]
    at org.elasticsearch.bootstrap.Bootstrap.setup(Bootstrap.java:194) [elasticsearch-5.5.1.jar:5.5.1]
    at org.elasticsearch.bootstrap.Bootstrap.init(Bootstrap.java:351) [elasticsearch-5.5.1.jar:5.5.1]
    at org.elasticsearch.bootstrap.Elasticsearch.init(Elasticsearch.java:123) [elasticsearch-5.5.1.jar:5.5.1]
    at org.elasticsearch.bootstrap.Elasticsearch.execute(Elasticsearch.java:114) [elasticsearch-5.5.1.jar:5.5.1]
    at org.elasticsearch.cli.EnvironmentAwareCommand.execute(EnvironmentAwareCommand.java:67) [elasticsearch-5.5.1.jar:5.5.1]
    at org.elasticsearch.cli.Command.mainWithoutErrorHandling(Command.java:122) [elasticsearch-5.5.1.jar:5.5.1]
    at org.elasticsearch.cli.Command.main(Command.java:88) [elasticsearch-5.5.1.jar:5.5.1]
    at org.elasticsearch.bootstrap.Elasticsearch.main(Elasticsearch.java:91) [elasticsearch-5.5.1.jar:5.5.1]
    at org.elasticsearch.bootstrap.Elasticsearch.main(Elasticsearch.java:84) [elasticsearch-5.5.1.jar:5.5.1]
[2017-08-01T14:10:57,843][WARN ][o.e.b.BootstrapChecks    ] [VAfWGGZ] max file descriptors [65535] for elasticsearch process is too low, increase to at least [65536]
[2017-08-01T14:10:57,844][WARN ][o.e.b.BootstrapChecks    ] [VAfWGGZ] max number of threads [1024] for user [maserati] is too low, increase to at least [2048]
[2017-08-01T14:10:57,844][WARN ][o.e.b.BootstrapChecks    ] [VAfWGGZ] max virtual memory areas vm.max_map_count [65530] is too low, increase to at least [262144]
[2017-08-01T14:10:57,844][WARN ][o.e.b.BootstrapChecks    ] [VAfWGGZ] system call filters failed to install; check the logs and fix your configuration or disable system call filters at your own risk

针对文件描述符,调成 65536 ulimit -n 65536,如果提示没有权限,则可以在用户的 .bash_profile 中增加一行,退出用户重新登陆就可以。

针对 max number of threads 问题,修改 /etc/security/limits.d/90-nproc.conf 。

*          soft    nproc     2048
root       soft    nproc     unlimited

针对 max virtual memory areas ,修改 /etc/sysctl.conf。如果没有,就新增一行。

vm.max_map_count = 262144

针对 system_call_filter 可以,通过修改配置文件(elasticsearch.yml)关掉这个参数。

bootstrap.system_call_filter: false 

4、访问,出现下面的结果表示启动成功。

[root@iZ627x15h6pZ cloud]# curl http://localhost:9200
{
  "name" : "VAfWGGZ",
  "cluster_name" : "elasticsearch",
  "cluster_uuid" : "J9Tm5R2zRt2PkOSwtXj5Wg",
  "version" : {
    "number" : "5.5.1",
    "build_hash" : "19c13d0",
    "build_date" : "2017-07-18T20:44:24.823Z",
    "build_snapshot" : false,
    "lucene_version" : "6.6.0"
  },
  "tagline" : "You Know, for Search"
}

Logstash 安装

1、下载并解压 Logstash,本文用的 Logstash-5.5.1 版本

2、创建一个简单的配置文件 logstash_test.conf

input { stdin { } }
output {
  stdout { codec => rubydebug }
}

3、启动 logstash

./bin/logstash -f logstash_test.conf 

出现这些信息,表示启动成功了。

[2017-08-01T13:58:38,437][INFO ][logstash.pipeline        ] Pipeline main started
The stdin plugin is now waiting for input:
[2017-08-01T13:58:38,532][INFO ][logstash.agent           ] Successfully started Logstash API endpoint {:port=>9600}

4、与ElasticSearch配合。

Kibana 安装

1、下载 Kibana

2、修改配置

//启动端口 因为端口受限 所以变更了默认端口
server.port: 5601
//启动服务的ip
server.host: "本机ip"
//elasticsearch地址
elasticsearch.url: "http://localhost:9200”

3、启动程序

./bin/kibana

4、访问查看Kibana启动是否成功,并检索查看数据

http://localhost:5601

参考资料:
1、Download Logstash
2、ElasticSearch Download

rsyslog queue队列权威指南

实际上,队列在整个日志的生命周期中都存在,它是Rsyslog的核心,一般情况下,我们感觉不到它的存在;然而,从日志的产生到被处理的过程,都必须经过两个队列,一个是主消息队列(main message queue),另一个是动作队列(action queue)。通过下面的图片,可以理解得更加清楚:

[图片1]

从上图中可以看到,日志产生后,先经过预处理器然后就被压入main message queue等待后续的处理,在进入action queue之前,日志被解析器和过滤器处理,它们的作用是读取rsyslog.conf配置文件中设置的规则,和日志中的内容进行对比,然后发送到合适的action queue,一旦日志进入到这个action queue之后,就会从主消息队列中删除。

日志真正被处理的阶段发生在进入action queue之后,action processor(动作处理器)会从action queue中获取最先进入队列的日志进行处理,根据规则进行日志的输出,例如写入文件,录入数据库、发送到远程服务器,甚至是把它们丢弃。

rsyslog.conf中每一条规则的action都有一个action queue,这种queue默认类型是direct queue,但严格来说,它不属于队列,虽然名字中有queue字样。direct queue通常处理简单的行为,例如把日志写入本地文件。

在direct queue下,同一条日志如果被多个动作处理器消费,这个时候,同一条日志会被复制到各个动作队列中,那么可能会造成的现象是,当你使用discard丢弃日志的时候,会发现discard指令没有生效,原因是:discard指令丢弃的是原始日志的副本,而原始的日志会继续活动在原来的工作流中。

Java 21新特性

在最新的 Java 21 版本中, Oracle 开发团队为其带来了 15 大功能更新,详细如下:

  • 字符串模板(预览阶段)

    该功能通过将文字文本与嵌入式表达式和处理器相结合来产生专门的结果,从而补充了 Java 现有的字符串文字和文本块。该语言功能和 API 的目的是通过轻松表达包含运行时计算值的字符串来简化 Java 程序的编写。它有望增强表达式的可读性,提高程序的安全性,保持灵活性,并简化接受用非 Java 语言编写的字符串的 API 的使用。

  • 序列集合

    有序集合提案引入了一些接口,用于表示具有已定义遇到顺序的集合。每个集合都有明确定义的第一个和第二个元素,以此类推,直到最后一个元素。提供了一致的 API,用于接受第一个和最后一个元素以及以相反顺序处理元素。该提案的提出的原因是,Java 的集合框架缺乏一种表示具有定义的遇到顺序的元素序列的集合类型。它还缺乏适用于这些集合的一致的操作集。该提案要求定义顺序集合、集合和映射的接口,并将这些接口适应到现有的集合类型层次结构中。所有这些新方法都具有默认实现。

  • 加入 Generational ZGC

    分代 ZGC 的目的是通过扩展 ZGC,维护新旧对象的不同代,从而提高应用程序的性能。年轻的对象往往很早就会死亡;保持独立的世代将允许 ZGC 更频繁地收集年轻对象。使用分代 ZGC 运行的应用程序应能获得以下优势:降低分配停滞的风险、降低堆内存开销和降低垃圾回收 CPU 开销。与非分代 ZGC 相比,这些优势应该可以实现,而不会显著降低吞吐量。

  • 记录模式

    该功能在 JDK 19 和 JDK 20 中都是预览版,主要用于解构记录值。记录模式和类型模式可以嵌套,以实现强大、声明性和可组合的数据导航和处理形式。该提案的目标包括将模式匹配扩展到重组记录类实例,并添加嵌套模式,从而实现更多可组合的数据查询。当前 JEP(JDK 增强提案)中的记录模式提案将最终确定该功能,并根据不断积累的经验和反馈意见进一步完善。

  • switch 模式匹配

    该功能允许 switch 表达式或语句可以根据多个模式(每个模式都有特定的操作)进行测试,从而可以安全、简洁地表达面向数据的复杂查询。该功能最初在 JDK 17 中提出,随后在 JDK 18、JDK 19 和 JDK 20 中得到改进。它将在 JDK 21 中最终完成,并根据反馈和经验进一步完善。与以前的 JEP 相比,主要的变化是删除了括号模式,并允许使用限定的枚举常量(如带有 switch 表达式和语句的 case 常量)。

  • 外部函数与内存 API(第三次预览)

    允许 Java 程序与 Java 运行时之外的代码和数据进行互操作。通过有效地调用外部函数和安全访问外部内存,该 API 使 Java 程序能够调用本地库并处理本机数据,而不会出现 JNI(Java Native Interface)的脆弱性和危险性。该 API 先前在 JDK 20 和 JDK 19 中进行了预览。JDK 21 预览中的改进包括增强的布局路径,增加了一个用于取消引用地址布局的新元素,以及集中管理 Arena 接口中本地段的生命周期;实现了一个后备本地链接器;删除了 VaList。

  • 未命名模式和变量(预览版)

    未命名模式匹配记录组件,但不说明组件名称或类型,而未命名变量可以初始化但不能使用。两者都用下划线字符 _ 表示。该提案旨在通过省略不必要的嵌套模式来提高记录模式的可读性,并通过识别必须声明但不会使用的变量来提高所有代码的可维护性。

  • 虚拟线程

    虚拟线程是一种轻量级线程,有望大幅减少编写、维护和观察高吞吐量并发应用程序的工作量。在 JDK 21 中,虚拟线程将始终支持线程本地变量,并使创建不具备这些变量的虚拟线程成为不可能。对线程本地变量的有保证的支持确保更多的现有库可以不改变地与虚拟线程一起使用,并帮助迁移任务导向的代码以使用虚拟线程。

  • 未命名类和实例主要方法(处于预览阶段)

    该功能的作用是为了让学生能够更容易地编写出第一个 Java 程序,而无需了解为大型程序设计的语言功能。学生无需使用单独的 Java 方言,就能编写单类程序的精简声明,然后随着技能的提高,无缝扩展程序,使用更高级的功能。该提案不仅为学生提供了通往 Java 的平坦道路,还减少了编写脚本和命令行实用程序等简单 Java 程序的繁琐过程。

  • 作用域值(处于预览阶段)

    作用域值(Scoped values)是指允许在线程内和线程间共享不可变数据。作用域值允许在大型程序的组件之间安全地共享数据,而无需使用方法参数。这一提议在 JDK 20 中得到了验证。该计划的目标包括易用性、可理解性、健壮性和性能。

  • 矢量 API(第六个孵化器)

    该 API 表达的矢量计算可在支持的 CPU 架构上可靠地编译为最佳矢量指令,从而实现优于同等标量计算的性能。此前,矢量 API 已在 JDK 16 至 JDK 20 中孵化。最新版本包括性能增强和错误修复。该提案的目标包括:简洁明了、与平台无关、在 x64 和 AArch64 体系结构上提供可靠的运行时编译和性能。

  • 弃用 Windows 32 位 x86 端口

    这个功能更新的目的是在未来的版本中删除该端口。该提案旨在更新构建系统,以便在尝试为 32 位 x86 Windows 配置构建时,发出错误消息。该提案指出,支持 32 位操作的最后一个 Windows 操作系统版本之 Windows 10 将于 2025 年 10 月终止生命周期。

  • 禁止代理的动态加载

    当代理被动态加载到运行中的 JVM 时发出警告。发出这些警告的目的是为将来发布默认禁止加载代理的版本做准备,以改善默认情况下的完整性。该提案的其他目标包括重新评估服务性(涉及对运行中代码的临时更改)和完整性(假定运行中的代码不会被随意更改)之间的平衡,并确保大多数不需要动态加载代理的工具不受影响。从 JDK 21 开始,计划要求应用程序所有者批准动态加载代理,就像启动时加载代理一样。这个改变将使 Java 平台更接近默认情况下的完整性。

  • 密钥封装机制的 API

    这一种通过公开密码学保护对称密钥的加密技术。该提案的一个目标是使应用程序能够使用 KEM 算法,如 RSA 密钥封装机制(RSA-KEM)、椭圆曲线集成加密方案(ECIES)和美国国家标准与技术研究院(NIST)后量子密码标准化过程的候选算法。另一个目标是在更高级别的协议(如传输层安全性(TLS))和密码方案(如混合公钥加密(HPKE))中使用 KEM。安全提供商可以在 Java 代码或本地代码中实现 KEM 算法,并包括在 RFC 9180 中定义的 Diffie-Hellman KEM(DHKEM)的实现。

  • 结构化并发(目前处于预览阶段)

    通过结构化并发 API 简化并发编程,将在不同线程中运行的相关任务组视为单个工作单元。这简化了错误处理和取消操作,提高了可靠性并增强了可观察性。结构化并发之前分别于 2022 年 3 月和 9 月在 JDK 20 和 JDK 19 中孵化,它作为 java.util.concurrent 包中的一个预览 API。这次唯一的重大变化是,StructuredTaskScope::Fork(…) 方法返回的是 [Subtask] 而不是 Future。结构化并发的目标包括促进一种并发编程风格,这种风格可以消除因取消和关闭而产生的常见风险(如线程泄漏和取消延迟),同时提高并发代码的可观察性。

Kafka删除topic的方法

在运营环境中,删除kafka topic的方法,没有必要当然不要这么干,迫不得已才会去删除topic。

首先配置文件server.properties 增加参数 delete.topic.enable=true

其次呢,使用删除命令行:

./bin/kafka-topics.sh –delete –topic THIS_IS_MY_TOPIC –zookeeper localhost:2181

*红色字体需要替换。

或者使用kafka-manager集群管理工具删除。

如果删除之前,没有配置 delete.topic.enable=true 参数,那么topic只会标记为marked for deletion ,也就是说,只是标记并没有删除;

此时只要加上配置项,然后重启kafka就可以真正删除该topic。

如果重启还是没有被删除,那么就使用zookeeper的命令删除试试;

输入工具行命令: ./zookeeper-3.4.10/bin/zkCli.sh

此时进入了一个shell中端。

执行:ls /brokers/topics 命令可以查看当前brokers下所有topics。

然后执行: rmr /brokers/topics/[topic name] 删除指定的topic,但是可能会提示:

The command ‘rmr’ has been deprecated. Please use ‘deleteall’ instead.

只要把rmr换成deleteall就可以了,如:

deleteall /brokers/topics/[topic name]

再次使用ls /brokers/topics 命令查看topics,如果发现你要删除的topic还在,

执行:ls /admin/delete_topics  这里会显示出你刚刚要删除的topic,然后执行:deleteall /admin/delete_topics/[topic name]  就可以完全删除了。

总结一下:

1.执行:

./bin/kafka-topics.sh –delete –topic THIS_IS_MY_TOPIC –zookeeper localhost:2181

2.如果没有删除:

配置文件server.properties 增加参数 delete.topic.enable=true

3.重启kafka

4.还是没有删除:

执行:./zookeeper-3.4.10/bin/zkCli.sh

执行:ls /brokers/topics 命令可以查看当前brokers下所有topics

执行:deleteall /brokers/topics/[topic name]

 

5.再次使用ls /brokers/topics 命令查看topics,如果发现你要删除的topic还在

执行:ls /admin/delete_topics

执行:deleteall /admin/delete_topics/[topic name] 

结束完成。比较麻烦,但是有效解决在kafka使用过程中如果有需要删除topic而又删除失败。

123432
 
Copyright © 2008-2021 lanxinbase.com Rights Reserved. | 粤ICP备14086738号-3 |