The next and last part of our stack is the filesystem layer. This is where the PostgreSQL data will reside, so we need to ensure it's allocated properly. Unlike the underlying LVM layers, the filesystem is not so easily modified.
In this recipe, we will discuss some common formatting options and why we recommend them in addition to necessary commands.
Since this is the last layer in our complete stack, we strongly suggest following all the recipes up to Incorporating the second LVM layer before starting here.
Assuming pg1 is our current primary node, follow these steps there as the root user:
- Activate the second LVM volume with this command:
lvchange -a y VG_POSTGRES/LV_DATA - Count the number of CPUs on the primary node.
- Multiply the CPU count by four.
- If the total in the previous step is less than 256, use 256.
- Use this command to find the Linux kernel version:
uname -r - For kernel versions
3.0and above, format the XFS filesystem with this command, settingagcountto the value derived in the preceding steps:mkfs.xfs -d agcount=256 /dev/VG_POSTGRES/LV_DATA - For kernels below
3.0, format with this command:mkfs.xfs -d agcount=256 -l size=128m -l lazy-count=1 -i attr=2 /dev/VG_POSTGRES/LV_DATA
We begin by activating (-a y) the VG_POSTGRES/LV_DATA volume with lvchange. This is like vgchange, but only affects the named volume, instead of every volume in the named group. We used this command merely to demonstrate that either command will work for our stack, especially since there is only one volume to activate.
The next three steps involve a simple calculation, but it deserves some explanation. The main feature we want to exploit here is the count of allocation groups. Each allocation group can be addressed independently when making filesystem modifications. Presumably, this enhances performance in several different categories since it reduces allocation table contention.
To reach our desired number, we start with the total CPU count in our primary server. This is the maximum number of concurrent processes that can touch the filesystem simultaneously. However, we live in a world where upgrades are frequent and CPU core counts are only increasing. Thus, we suggest multiplying the current CPU count by four, because we only get one chance to create the XFS layer once it contains data. We want to keep time-consuming data migrations to a minimum if possible.
With this calculated allocation group count in hand, we can begin formatting. The mkfs.xfs utility supplied by xfsprogs will perform this step for us. The command we used contained several parameters, separated into data (-d), log (-l), and inode (-i) settings. Here is a quick summary of what these options do:
- The
agcountsetting defines how many allocation groups XFS should create. Our example uses256, but you may have more. - We set the log
sizeto128mfor a 128 MB journal. Journaling filesystems are not new, but we need a sufficient size to track many concurrent changes on active databases. On kernels at and above3.0, this value is calculated based on the device size, so we don't need to set it. - By setting
lazy-countto1, we get the full power of ouragcountsetting. Though there are several allocation groups, there is still a master superblock that tracks some universal counters. By enabling this, XFS uses other techniques to maintain these values, avoiding sequential superblock access. On kernels3.0and higher, this is set to1by default. - The
attrinode setting configures an internal mechanism to store inline attributes. This is more of an implementation detail, but Version2is more efficient. On kernels above2.6.16, this is set to2by default.
While this is a lot to digest, it should be clear by now that newer kernels make it much easier to use XFS. Instead of all these other options, we merely need to set agcount and format the filesystem. If everything works as expected, we should see this output from the mkfs.xfs command:
From this, we can see that our agcount is indeed set to 256, lazy-count is set to 1, and attr is set to 2.