| Time |
Nick |
Message |
| 05:01 |
|
kworstell-isl joined #evergreen |
| 05:02 |
|
kworstell_isl joined #evergreen |
| 07:00 |
|
collum joined #evergreen |
| 07:36 |
|
sandbergja joined #evergreen |
| 08:01 |
|
kworstell_isl joined #evergreen |
| 08:01 |
|
kworstell-isl joined #evergreen |
| 08:03 |
|
kworstell-isl joined #evergreen |
| 08:06 |
|
BDorsey joined #evergreen |
| 08:29 |
|
mmorgan joined #evergreen |
| 09:02 |
|
Dyrcona joined #evergreen |
| 09:48 |
|
JBoyer joined #evergreen |
| 09:55 |
|
sleary joined #evergreen |
| 09:58 |
|
Stompro joined #evergreen |
| 10:09 |
|
jblyberg joined #evergreen |
| 10:20 |
|
sandbergja joined #evergreen |
| 10:21 |
Dyrcona |
Hmm. That's a "large" file: 2.8GB for 473,135 bibs with items as XML. I sometimes think that XML was invented by storage manufacturers so that we would need larger drives. :) |
| 10:21 |
Bmagic |
lol, that's funny |
| 10:22 |
Dyrcona |
I should timed how long it took to export those records. It finished at 00:15 EDT today. I forget what time I started it yesterday. |
| 10:23 |
Stompro |
ZFS compression was developed to fight back for the users. |
| 10:24 |
Dyrcona |
ZFS++ |
| 10:25 |
Dyrcona |
I use ZFS on the PostgreSQL partition of my test servers (forme produciton servers). I have 2 NVMe drives configured in a ZFS array, currently striped, previously mirrored in production. |
| 10:26 |
Dyrcona |
btrfs can compress files, too, can't it? |
| 10:27 |
Stompro |
I'm using ZFS on our new production DB and app servers, migrating to 3.11.1 on Saturday. Using raid10 mode. |
| 10:28 |
Stompro |
1.78x compression for the DB, 2.23x for the wal files |
| 10:29 |
Dyrcona |
Stompro: Cool. I like that ZFS can just "do the RAID" without hardware or software REAID (/dev/md) being required. |
| 10:29 |
Dyrcona |
I don't think I enabled compression. I could check. |
| 10:29 |
Dyrcona |
I guess technically ZFS calls it a "pool" not RAID, but it's the same idea depending on how you configure it. |
| 10:30 |
Dyrcona |
Also, to answer my previous question: No, btrfs does not do compression. It seems that be antithetical to its aims. |
| 10:31 |
Dyrcona |
I keep words.... :) |
| 10:31 |
Dyrcona |
^omitting|dropping....One of them goes in there somewhere. :) |
| 10:34 |
berick |
zfs++ for lxd vm's |
| 10:35 |
Stompro |
I'm using pgbackrest for PG backups now, pretty neat project. |
| 10:55 |
|
briank joined #evergreen |
| 11:25 |
|
smayo joined #evergreen |
| 11:25 |
|
Christineb joined #evergreen |
| 11:26 |
berick |
Stompro: same re: pgbackrest. i didn't set it up, but it's working well. made creating clones of prod DB pretty easy. |
| 12:03 |
jeffdavis |
is pgbackrest significantly faster than pg_dump/pg_restore? |
| 12:17 |
berick |
jeffdavis: i've never done a dump/restore of our prod db. i only recently started doing the db sync's myself. previous solution was also related to how we made backups, i think, and i recall it being more cumbersome. |
| 12:17 |
berick |
i would expect it to be faster, since you essentially already have a data dump from the backup + transaction logs (as i understand it) |
| 12:30 |
JBoyer |
I'm a big fan of barman for backups and repmgr for replication. Very nice. |
| 13:38 |
|
sleary joined #evergreen |
| 14:06 |
|
jihpringle joined #evergreen |
| 15:33 |
|
jihpringle joined #evergreen |
| 15:38 |
|
jihpringle joined #evergreen |
| 17:04 |
|
mmorgan left #evergreen |
| 17:10 |
|
sandbergja joined #evergreen |
| 20:20 |
|
kworstell-isl joined #evergreen |
| 23:08 |
|
kworstell-isl joined #evergreen |
