Rootop 服务器运维与web架构

2024-04-08
发表者 Venus
ubuntu中修改mysql的datadir目录启动失败Permission denied已关闭评论

ubuntu中修改mysql的datadir目录启动失败Permission denied

在Ubuntu中atp安装的mysql,默认数据目录在/var/lib/mysql ,添加了一块硬盘,需要将数据目录改为独立硬盘中。
修改mysql配置文件后重启报错,提示权限拒绝,修改了目录属主属组仍旧不行。

root@iZwz9g269i424nee31ly7yZ:/mysql/data# systemctl status mysql
● mysql.service - MySQL Community Server
     Loaded: loaded (/lib/systemd/system/mysql.service; enabled; vendor preset: enabled)
     Active: failed (Result: exit-code) since Sun 2024-04-07 17:14:53 CST; 10s ago
    Process: 891921 ExecStartPre=/usr/share/mysql/mysql-systemd-start pre (code=exited, status=0/SUCCESS)
    Process: 891929 ExecStart=/usr/sbin/mysqld (code=exited, status=1/FAILURE)
   Main PID: 891929 (code=exited, status=1/FAILURE)
     Status: "Server shutdown complete"
      Error: 13 (Permission denied)

Apr 07 17:14:53 iZwz9g269i424nee31ly7yZ systemd[1]: mysql.service: Scheduled restart job, restart counter is at 5.
Apr 07 17:14:53 iZwz9g269i424nee31ly7yZ systemd[1]: Stopped MySQL Community Server.
Apr 07 17:14:53 iZwz9g269i424nee31ly7yZ systemd[1]: mysql.service: Start request repeated too quickly.
Apr 07 17:14:53 iZwz9g269i424nee31ly7yZ systemd[1]: mysql.service: Failed with result 'exit-code'.
Apr 07 17:14:53 iZwz9g269i424nee31ly7yZ systemd[1]: Failed to start MySQL Community Server.

最终发现是apparmor这个服务导致的,apparmor是与selinux类似的访问控制机制。

root@iZwz9g269i424nee31ly7yZ:~# cat /etc/apparmor.d/usr.sbin.mysqld 
将
# Allow data dir access
  /var/lib/mysql/ r
  /var/lib/mysql/** rwk

改为
# Allow data dir access
  /mysql/data/ r,
  /mysql/data/** rwk,

# 重启apparmor及mysql
root@iZwz9g269i424nee31ly7yZ:~# /etc/init.d/apparmor restart
root@iZwz9g269i424nee31ly7yZ:~# systemctl restart mysql

2024-04-08
发表者 Venus
rsyslog日志收集已关闭评论

rsyslog日志收集

# 日志收集端,存放客户端发送过来的日志

1、开启tcp接收
[root@localhost ~]# cat /etc/rsyslog.conf |grep -vE "^#|^$" | grep 514
$InputTCPServerRun 514

2、创建配置文件,定义存储路径。
[root@localhost ~]# cat /etc/rsyslog.d/119.conf 
$template NginxLog, "/var/log/nginx/%FROMHOST-IP%/%$YEAR%-%$MONTH%-%$DAY%/%PROGRAMNAME%.log"
if $programname == 'nginx-access' then -?NginxLog
if $programname == 'nginx-error' then -?NginxLog

%FROMHOST-IP% 以客户端ip命名目录
%$YEAR%-%$MONTH%-%$DAY% 年月日命名目录
%PROGRAMNAME%.log" 等于客户端中InputFileTag的值

最终效果如下:
[root@localhost ~]# ll /var/log/nginx/192.168.6.119/2024-04-07/*
-rw------- 1 root root 1997 Apr  7 02:10 /var/log/nginx/192.168.6.119/2024-04-07/nginx-access.log
-rw------- 1 root root 1694 Apr  7 02:10 /var/log/nginx/192.168.6.119/2024-04-07/nginx-error.log
目录会自动创建,不需要手动提前建好。

[root@localhost ~]# systemctl restart rsyslog

# 日志发送端

[root@localhost ~]# cat /etc/rsyslog.d/nginx.conf 
$ModLoad imfile
$InputFilePollInterval 5
$WorkDirectory /var/spool/rsyslog
$PrivDropToGroup root

$InputFileName /var/log/nginx/access.log
$InputFileTag nginx-access:
$InputFileStateFile stat-nginx-access
$InputFileSeverity info
$InputFilePersistStateInterval 25000
$InputRunFileMonitor

$InputFileName /var/log/nginx/error.log
$InputFileTag nginx-error:
$InputFileStateFile stat-nginx-error
$InputFileSeverity info
$InputFilePersistStateInterval 25000
$InputRunFileMonitor
*.* @@192.168.6.114:514

# @@是以tcp方式发送到目标ip的514端口。

2024-03-21
发表者 Venus
logrotate参数解释已关闭评论

logrotate参数解释

compress                 #通过gzip 压缩转储以后的日志
nocompress               #不做gzip压缩处理
copytruncate             #用于还在打开中的日志文件,把当前日志备份并截断;是先拷贝再清空的方式,拷贝和清空之间有一个时间差,可能会丢失部分日志数据。
nocopytruncate           #备份日志文件不过不截断
create mode owner group  #轮转时指定创建新文件的属性,如create 0777 nobody nobody
nocreate                 #不建立新的日志文件
delaycompress            #和compress 一起使用时,转储的日志文件到下一次转储时才压缩
nodelaycompress          #覆盖 delaycompress 选项,转储同时压缩。
missingok                #如果日志丢失,不报错继续滚动下一个日志
errors address           #专储时的错误信息发送到指定的Email 地址
ifempty                  #即使日志文件为空文件也做轮转,这个是logrotate的缺省选项。
notifempty               #当日志文件为空时,不进行轮转
mail address             #把转储的日志文件发送到指定的E-mail 地址
nomail                   #转储时不发送日志文件
olddir directory         #转储后的日志文件放入指定的目录,必须和当前日志文件在同一个文件系统
noolddir                 #转储后的日志文件和当前日志文件放在同一个目录下
sharedscripts            #运行postrotate脚本,作用是在所有日志都轮转后统一执行一次脚本。如果没有配置这个,那么每个日志轮转后都会执行一次脚本
prerotate                #在logrotate转储之前需要执行的指令,例如修改文件的属性等动作;必须独立成行
postrotate/endscript     #在logrotate转储之后需要执行的指令,例如重新启动 (kill -HUP) 某个服务!必须独立成行
daily                    #指定转储周期为每天
weekly                   #指定转储周期为每周
monthly                  #指定转储周期为每月
rotate count             #指定日志文件删除之前转储的次数,0 指没有备份,5 指保留5 个备份
dateext                  #使用当期日期作为命名格式
dateformat .%s           #配合dateext使用,紧跟在下一行出现,定义文件切割后的文件名,必须配合dateext使用,只支持 %Y %m %d %s 这四个参数
size(或minsize) log-size #当日志文件到达指定的大小时才转储,log-size能指定bytes(缺省)及KB (sizek)或MB(sizem).

当日志文件 >= log-size 的时候就转储。 以下为合法格式:(其他格式的单位大小写没有试过)
size = 5 或 size 5 (>= 5 个字节就转储)#满足size就滚动一次,size参数跟滚动周期参数:hourly、daily、monthly、yearly完全是互斥的。即一旦设置了size参数,滚动周期参数就自动无效了,只要每次执行logrotate指令时,日志文件大小超过size,就会触发一次滚动,没有滚动周期一说了
size = 100k 或 size 100k
size = 100M 或 size 100M
maxsize 100k    #一般用于多次轮询;当执行logrorate指令时,只要日志的大小超过100k,即使时间没到下一个滚动周期内,也会发生滚动。那么同一小时内0:00--0:59就会发生多次滚动。换句话说,如果demo.txt的大小一直没有达到maxsize,那么一个滚动周期就只会发生一次滚动,即当前滚动周期内第一次执行logrorate指令就会触发滚动。以后的59分钟都不会发生滚动。maxsize可以使滚动提前发生,再下一个滚动周期到来之前发生多次滚动。即每满足maxsize就滚动一次,不满足则滚动1次,(每个滚动周期内,n次或1次)
【maxsize size】: Log files are rotated when they grow bigger than size bytes even before the additionally specified time interval (daily, weekly, monthly, or yearly).  The related size  option is  similar except that it is mutually exclusive with the time interval options, and it causes log files to be rotated without regard for the last rotation time.  When maxsize is used, both the size and timestamp of a log file are considered.
minsize   100k     #一个滚动周期内只会发生一次滚动,在当前滚动周期后面的时间里,即使日志大小再次超过100k,也不会再发生滚动,即minsize不能使滚动提前发生。如果日志的大小一直没有达到minsize,那么这个滚动周期内是不会触发滚动的。即满足minsize则滚动一次,不满足则滚动0次,(每个滚动周期内,1次或0次)。
maxage  60     #自动删除掉超过maxage指定天数的切割后的归档文件,即最大保留60天;相对于rotate按文件数,它是以天数为单位的



logrotate -d /etc/logrotate.conf
Logrotate是基于CRON来运行的,其脚本是/etc/cron.daily/logrotate,日志轮转是系统自动完成的。
实际运行时,Logrotate会调用配置文件/etc/logrotate.conf。可以在/etc/logrotate.d目录里放置自定义好的配置文件,用来覆盖Logrotate的缺省值。
https://blog.csdn.net/m0_68431045/article/details/128347031

2024-03-14
发表者 Venus
doris维护部分查询方法已关闭评论

doris维护部分查询方法

# 查看数据库id对应的数据库名
mysql> show database 11237;

# 查看表id对应的表名 
mysql> show table 239829;

# 查看表有哪些分区
mysql> show partitions from base_transfer\G;

# 过滤
mysql> show partitions from base_transfer where `partitionid` = 239780; # 值不能加引号,要不查不出来

# 查看建表语句
mysql> show create table base_transfer\G;

# 查看副本状态
mysql> ADMIN SHOW REPLICA STATUS FROM base_transfer;
+----------+-----------+-----------+---------+-------------------+--------------------+------------------+------------+------------+-------+--------+--------+
| TabletId | ReplicaId | BackendId | Version | LastFailedVersion | LastSuccessVersion | CommittedVersion | SchemaHash | VersionNum | IsBad | State  | Status |
+----------+-----------+-----------+---------+-------------------+--------------------+------------------+------------+------------+-------+--------+--------+
| 270021   | 270022    | 11126     | 1       | -1                | 1                  | 1                | 564419587  | 1          | false | NORMAL | OK     |
| 270023   | 270024    | 11180     | 1       | -1                | 1                  | 1                | 564419587  | 1          | false | NORMAL | OK     |
| 270025   | 270026    | 11181     | 1       | -1                | 1                  | 1                | 564419587  | 1          | false | NORMAL | OK     |

# 过滤
mysql> ADMIN SHOW REPLICA STATUS FROM base_transfer where status != 'OK';
更多状态参考:https://doris.apache.org/zh-CN/docs/2.0/sql-manual/sql-reference/Database-Administration-Statements/ADMIN-SHOW-REPLICA-STATUS

# 查看分片
mysql> show tablet 270891;

表table -> 分区partition -> 分片(桶)tablet


# 数据库id 表id从web中查看/System?path=/dbs/11237,或者通过 show proc "/"; 查看
SHOW PROC '/dbs/11237/1563242/partitions/1563239/1563243';

更多show proc用法参考:https://doris.apache.org/zh-CN/docs/2.0/sql-manual/sql-reference/Show-Statements/SHOW-PROC

# 建表
CREATE TABLE `base_test111111` (
  `block_number` largeint(40) NULL,
  `block_time` datetime NULL,
  `trans_hash` varchar(120) NULL,
  `log_index` int(11) NULL,
  `from_address` varchar(120) NULL,
  `to_address` varchar(120) NULL,
  `quantity` varchar(120) NULL,
  `amount_usd` varchar(120) NULL,
  `token_id` varchar(120) NULL,
  `token_address` varchar(120) NULL,
  `wallet_from` varchar(120) NULL,
  `wallet_to` varchar(120) NULL,
  `_id` varchar(120) NOT NULL,
  INDEX block_number_index (`block_number`) USING BITMAP COMMENT '区块号',
  INDEX block_time_index (`block_time`) USING BITMAP COMMENT '区块时间'
) ENGINE=OLAP
UNIQUE KEY(`block_number`, `block_time`, `trans_hash`, `log_index`)
COMMENT 'base_transfer交易表'
PARTITION BY RANGE(`block_time`)
(
PARTITION month_202401 VALUES [('2024-01-01 00:00:00'), ('2024-02-01 00:00:00')),
PARTITION month_202402 VALUES [('2024-02-01 00:00:00'), ('2024-03-01 00:00:00')),
PARTITION month_202403 VALUES [('2024-03-01 00:00:00'), ('2024-04-01 00:00:00')),
PARTITION month_202404 VALUES [('2024-04-01 00:00:00'), ('2024-05-01 00:00:00')),
PARTITION month_202405 VALUES [('2024-05-01 00:00:00'), ('2024-06-01 00:00:00'))
)
DISTRIBUTED BY HASH(`trans_hash`) BUCKETS 10 # 设置桶的数量,1.2.2版本之后可以设置为自动 BUCKETS AUTO
PROPERTIES (
"replication_num" = "3" # 副本集数,也就是每个桶有几个副本。
);

2024-03-08
发表者 Venus
juniper重启web管理界面服务已关闭评论

juniper重启web管理界面服务

juniper web配置界面,点开菜单后,右侧的配置信息不显示,要么显示不完整,要么修改内容无法保存。
但是通过命令行是能看到配置信息,所以问题出在web服务上。

固件版本是 20.4R2.7

通过浏览器F12调试模式,看到是往下面地址发起请求

https://10.1.2.1:60000/cache.php

响应内容

{
    "status": true,
    "jweb-config-cache": "\/jail\/var\/cache\/.91714653_root_cfg.json",
    "jweb-last-cache-update-time": "1709866189"
}

推测 /jail/var/cache/ 这个路径下是临时缓存文件,进到此目录,删掉文件。

root@juniper1% cd /jail/var/cache/
root@juniper1% ls -l
total 372
-rw-r--r--  1 root  wheel  77776 Mar  7 21:50 .2119246741_root_cfg.json
-rw-r--r--  1 root  wheel  34373 Mar  7 21:47 .91311285_super_lpad.json
-rw-r--r--  1 root  wheel  77776 Mar  7 21:50 .91714653_root_cfg.json

root@juniper1% rm -f .xxxxx # 删除了 以点开头的文件 .xxxxx

# 重启web界面服务
root@juniper1> restart web-management 

配置界面功能恢复。

web界面配置还是相对不如命令行稳定。