tsc_chazz's questions

我们有一个用于 GIS 数据库的系统（以 Postgres 作为底层引擎），该系统使用 4x2TB Samsung EVO870 SATA SSD 的软件 RAID 5 阵列作为其数据库驱动器。有一个夜间备份脚本，可将表转储到本地临时目录，对它们进行 GZip 压缩，然后将它们传输到单独的计算机（使用mv）。一般备份从1830开始一直运行到0500；是的，这是一个很大的备份。一个月左右前，外部系统掉线了，所以mv步骤停止工作，临时存储区域被未移动的文件填满。修复外部系统后，我们注意到临时区域已满，并删除了其中的所有内容 - 大约 3.5TB 的文件。大约两周前，我们注意到每日备份直到 1000 才完成。我怀疑事情已经变慢，因为临时目录虽然被删除，但没有被清除，所以当我们必须编写一个新的临时文件作为一部分时对于备份，我们必须先清理 SSD 块，然后才能重写它们。

fstrim -av不打印任何内容，这表明没有文件系统表示它们支持 DISCARD。

该系统在 RAID 阵列之上确实有 LVM。数据库和临时目录位于 ext4 文件系统中（是 ext2，但发生了一些事情），位于其自己的 LV 中，安装在/db；fstrim -v /db报道File system does not support DISCARD。

操作系统版本：Debian Linux 8 (jessie)、Linux 3.16.0-4-amd64 x86_64

RAID 信息：

root@local-database:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4] 
md0 : active raid5 sda1[7] sdd1[4] sdc1[5] sdb1[6]
      5860147200 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/4] [UUUU]
      bitmap: 1/2 pages [4KB], 524288KB chunk

root@local-database:~# mdadm --detail /dev/md0
/dev/md0:
        Version : 1.2
  Creation Time : Sun Dec 27 17:55:35 2015
     Raid Level : raid5
     Array Size : 5860147200 (5588.67 GiB 6000.79 GB)
  Used Dev Size : 1953382400 (1862.89 GiB 2000.26 GB)
   Raid Devices : 4
  Total Devices : 4
    Persistence : Superblock is persistent

  Intent Bitmap : Internal

    Update Time : Tue Aug  8 14:07:27 2023
          State : clean 
 Active Devices : 4
Working Devices : 4
 Failed Devices : 0
  Spare Devices : 0

         Layout : left-symmetric
     Chunk Size : 512K

           Name : local-database:0  (local to host local-database)
           UUID : 18d38d9a:daaa0652:8e43a020:133e5a4f
         Events : 53431

    Number   Major   Minor   RaidDevice State
       7       8        1        0      active sync   /dev/sda1
       6       8       17        1      active sync   /dev/sdb1
       5       8       33        2      active sync   /dev/sdc1
       4       8       49        3      active sync   /dev/sdd1

有关用于数据库和临时区域的特定 LV 的信息：

  --- Logical volume ---
  LV Path                /dev/MainDisk/postgres
  LV Name                postgres
  VG Name                MainDisk
  LV UUID                TpKgGe-oHKS-Y341-029v-jkir-lJn8-jo8xmZ
  LV Write Access        read/write
  LV Creation host, time local-database, 2015-12-27 18:04:04 -0800
  LV Status              available
  # open                 1
  LV Size                4.78 TiB
  Current LE             1251942
  Segments               4
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     6144
  Block device           253:2

光伏信息：

root@local-database:~# pvdisplay
  --- Physical volume ---
  PV Name               /dev/md0
  VG Name               MainDisk
  PV Size               5.46 TiB / not usable 2.50 MiB
  Allocatable           yes 
  PE Size               4.00 MiB
  Total PE              1430699
  Free PE               121538
  Allocated PE          1309161
  PV UUID               N3tcTa-LBw2-D8gI-6Jg4-9v3T-KWn2-5CDVzK

我真的很希望将备份时间缩短至 11 小时，这样我们就不会再与实际工作时间冲突。TRIM 选项中是否有我可以在此处执行的操作，或者还有其他我错过的操作吗？我检查过数据库没有突然增加任何新表，或者一夜之间增加了 50%；没有网络连接问题，据我所知，在我们开始花费 16 小时进行备份之前，网络或外部服务器没有发生任何奇怪的情况。我还缺少什么吗？

根据评论进行编辑：实际的 SSD 仅使用了一年半，于 2022 年 4 月取代了原来的 250GB SSD。（空间不足，RAID 阵列、LV 和文件系统已就位扩展。）使用软件 RAID、骨标准 Linux 和mdadm.

编辑回应评论：

root@local-database:~# lsblk -d
NAME MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda    8:0    0  1.8T  0 disk
sdb    8:16   0  1.8T  0 disk
sdc    8:32   0  1.8T  0 disk
sdd    8:48   0  1.8T  0 disk

root@local-database:~# cat /sys/module/raid456/parameters/devices_handle_discard_safely
N

root@local-database:~# lscpu
Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                8
On-line CPU(s) list:   0-7
Thread(s) per core:    2
Core(s) per socket:    4
Socket(s):             1
NUMA node(s):          1
Vendor ID:             AuthenticAMD
CPU family:            21
Model:                 2
Model name:            AMD FX(tm)-8320 Eight-Core Processor
Stepping:              0
CPU MHz:               1400.000
CPU max MHz:           3500.0000
CPU min MHz:           1400.0000
BogoMIPS:              7023.19
Virtualization:        AMD-V
L1d cache:             16K
L1i cache:             64K
L2 cache:              2048K
L3 cache:              8192K
NUMA node0 CPU(s):     0-7

根据 Nikita Kyprianov 在下面的评论中链接的一篇文章，三星 EVO 870s 在 AMD 硬件上存在严重问题，这显然是事实。看来就是这样。我想我们只能忍受它......

这是一个 Mint 21.1 x64 Linux 系统，多年来一直将磁盘添加到 RAID 阵列，直到我们现在拥有一个 10 3TB 的阵列和一个 5 6TB 的阵列。四个 HD 从阵列中掉出，每个两个，显然是由于一个控制器出现故障。我们已经更换了控制器，但这并没有恢复阵列的功能。mdadm --assemble报告无法启动任何一个阵列，磁盘不足（每个都有两个失败，我并不感到惊讶）；mdadm --run报告 I/O 错误（syslog 似乎表明这是因为它无法启动所有驱动器，但没有迹象表明它试图启动两个明显不愉快的驱动器），但我仍然可以出现故障磁盘并且它们看起来绝对mdadm --examine正常. 这是功能驱动器的输出：

mdadm --examine /dev/sda
/dev/sda:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x1
     Array UUID : 829c0c49:033a810b:7f5bb415:913c91ed
           Name : DataBackup:back  (local to host DataBackup)
  Creation Time : Mon Feb 15 13:43:15 2021
     Raid Level : raid5
   Raid Devices : 10

 Avail Dev Size : 5860268976 sectors (2.73 TiB 3.00 TB)
     Array Size : 26371206144 KiB (24.56 TiB 27.00 TB)
  Used Dev Size : 5860268032 sectors (2.73 TiB 3.00 TB)
    Data Offset : 264192 sectors
   Super Offset : 8 sectors
   Unused Space : before=264112 sectors, after=944 sectors
          State : clean
    Device UUID : 6e072616:2f7079b0:b336c1a7:f222c711

Internal Bitmap : 8 sectors from superblock
    Update Time : Sun Apr  2 04:30:27 2023
  Bad Block Log : 512 entries available at offset 24 sectors
       Checksum : 2faf0b93 - correct
         Events : 21397

         Layout : left-symmetric
     Chunk Size : 512K

   Device Role : Active device 9
   Array State : AAAAAA..AA ('A' == active, '.' == missing, 'R' == replacing)

这是一个故障驱动器的输出：

mdadm --examine /dev/sdk
/dev/sdk:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x1
     Array UUID : 829c0c49:033a810b:7f5bb415:913c91ed
           Name : DataBackup:back  (local to host DataBackup)
  Creation Time : Mon Feb 15 13:43:15 2021
     Raid Level : raid5
   Raid Devices : 10

 Avail Dev Size : 5860268976 sectors (2.73 TiB 3.00 TB)
     Array Size : 26371206144 KiB (24.56 TiB 27.00 TB)
  Used Dev Size : 5860268032 sectors (2.73 TiB 3.00 TB)
    Data Offset : 264192 sectors
   Super Offset : 8 sectors
   Unused Space : before=264112 sectors, after=944 sectors
          State : clean
    Device UUID : d62b85bc:fb108c56:4710850c:477c0c06

Internal Bitmap : 8 sectors from superblock
    Update Time : Sun Apr  2 04:27:31 2023
  Bad Block Log : 512 entries available at offset 24 sectors
       Checksum : d53202fe - correct
         Events : 21392

         Layout : left-symmetric
     Chunk Size : 512K

   Device Role : Active device 6
   Array State : AAAAAAAAAA ('A' == active, '.' == missing, 'R' == replacing)

编辑：这是来自第二个故障驱动器的 --examine 报告；如您所见，它在整个阵列掉线的同时失败了。

# mdadm --examine /dev/sdl
/dev/sdl:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x1
     Array UUID : 829c0c49:033a810b:7f5bb415:913c91ed
           Name : DataBackup:back  (local to host DataBackup)
  Creation Time : Mon Feb 15 13:43:15 2021
     Raid Level : raid5
   Raid Devices : 10

 Avail Dev Size : 5860268976 sectors (2.73 TiB 3.00 TB)
     Array Size : 26371206144 KiB (24.56 TiB 27.00 TB)
  Used Dev Size : 5860268032 sectors (2.73 TiB 3.00 TB)
    Data Offset : 264192 sectors
   Super Offset : 8 sectors
   Unused Space : before=264112 sectors, after=944 sectors
          State : clean
    Device UUID : 35ebf7d9:55148a4a:e190671d:6db1c2cf

Internal Bitmap : 8 sectors from superblock
    Update Time : Sun Apr  2 04:27:31 2023
  Bad Block Log : 512 entries available at offset 24 sectors
       Checksum : c13b7b79 - correct
         Events : 21392

         Layout : left-symmetric
     Chunk Size : 512K

   Device Role : Active device 7
   Array State : AAAAAAAAAA ('A' == active, '.' == missing, 'R' == replacing)

第二个阵列，5x6TB，两分钟后两个磁盘退出时掉线。这个阵列上的两个故障磁盘和另一个阵列上的两个故障磁盘都连接到一个 4 端口 SATA 控制器卡，当然现在已经被更换了。

我觉得有趣的主要事情是故障驱动器似乎报告自己还活着，但mdadm并不同意。journalctl似乎没有回到 4 月 2 日，所以我可能无法查明发生了什么。任何人都知道我可以做些什么来让这只野兽重新上线？

我正在尝试让 SMTP-AUTH 在 Mint Linux 20.2 机器上运行，但无法进行身份验证。我已经安装了 Cyrus sasl2，并且显然配置正确 -testsaslauthd -u <user> -p <password> -s smtp返回0: OK "Success."但是当我尝试使用相同的凭据从我的客户端发送邮件时，sendmail 无法进行身份验证。让我感到好奇的是，当我使用testsaslauthd身份验证日志时会生成条目，但是当 Sendmail 尝试时，什么都没有。尝试testsaslauthd从非 root 上下文中使用也会导致没有身份验证条目，这让我相信要么sendmail没有足够的权限连接到 sasl 守护进程，要么它不知道该管道在哪里并且猜错了. 所以我想问题是，如何sendmail找到那个管道，当它这样做时它是谁？