Problema

Ao tentar aplicar patch em um Exadata X8, o patchmgr apresentou o seguinte erro em um dos DB Nodes:

ERROR: Inactive VAR LV /dev/mapper/VGExaDb-LVDbVar2 size (2048MB) is smaller than Active VAR LV /dev/mapper/VGExaDb-LVDbVar1 size(10240MB)

O Exadata mantém 2 volumes no LVM para o diretório /var, onde um dos volumes fica inativo servindo como backup do volume que está ativo atualmente durante as atualizações do Exa Software. O erro acima está alegando que o volume que encontra-se inativo possui um tamanho inferior ao volume que está ativo atualmente.

Exemplo:

[root@exax8db01 ~]# lvs | grep LVDbVar[1-9]
  LVDbVar1           VGExaDb -wi-ao----  10.00g
  LVDbVar2           VGExaDb -wi-a-----   2.00g

Essa é uma configuração indesejada e deve ter sido derivada de uma extensão do volume LVDbVar1 que não foi acompanhada por uma extensão do volume LVDbVar2 (no exemplo em questão, poderia ocorrer o inverso também).

Para corrigir o cenário, precisamos expandir o volume de menor tamanho para ficar igual ao volume de maior volume.

A questão é que para executar o processo de expanção fim a fim, precisamos do volume ativo. Para não interferir no funcionamento do SO mexendo no /var do ambiente, um caminho é montar esse volume em um diretório alternativo temporariamente apenas para concluir o processo de expanção.

Sugestão: Verifique a condição em todos os DB Nodes e aplique a correção em todos que apresentar essa divergência.

dcli -g ~/dbs_group -l root 'lvs | grep LVDbVar[1-9]'

Solução

1) Verifique o tamanho dos volumes no servidor:

lvs | grep LVDbVar[1-9]

2) Confirme qual volume está ativo no momento com o df:

df -h /var

3) Expanção do volume com o incremento necessário:

lvextend -L +8G /dev/VGExaDb/LVDbVar2

4) Cria um diretório temporário no servidor:

mkdir -p /tmp/varex

5) Monta o volume LVM que está inativo nesse diretório temporário:

mount -t xfs /dev/VGExaDb/LVDbVar2 /tmp/varex

6) Faz a expanção do filesystem XFS para o novo tamanho do volume:

xfs_growfs /tmp/varex

7) Agora pode desmontar o volume e remover o diretório temporário do servidor:

umount /tmp/varex
rm -rf /tmp/varex

8) Confirme que o tamanho dos dois volumes ficaram iguais:

lvs | grep LVDbVar[1-9]

Exemplo

[root@exax8db01 ~]# lvs | grep LVDbVar[1-9]
  LVDbVar1           VGExaDb -wi-ao----  10.00g
  LVDbVar2           VGExaDb -wi-a-----   2.00g

[root@exax8db01 ~]# lvextend -L +8G /dev/VGExaDb/LVDbVar2
  Size of logical volume VGExaDb/LVDbVar2 changed from 2.00 GiB (512 extents) to 10.00 GiB (2560 extents).
  Logical volume VGExaDb/LVDbVar2 successfully resized.


[root@exax8db01 ~]# mkdir -p /tmp/varex
[root@exax8db01 ~]# mount -t xfs /dev/VGExaDb/LVDbVar2 /tmp/varex
[root@exax8db01 ~]# xfs_growfs /tmp/varex
meta-data=/dev/mapper/VGExaDb-LVDbVar2 isize=256    agcount=8, agsize=65536 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=0        finobt=0 spinodes=0 rmapbt=0
         =                       reflink=0
data     =                       bsize=4096   blocks=524288, imaxpct=25
         =                       sunit=256    swidth=256 blks
naming   =version 2              bsize=4096   ascii-ci=0 ftype=1
log      =internal               bsize=4096   blocks=2560, version=2
         =                       sectsz=512   sunit=8 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
data blocks changed from 524288 to 2621440


[root@exax8db01 ~]# umount /tmp/varex
[root@exax8db01 ~]# rm -rf /tmp/varex
[root@exax8db01 ~]# lvs | grep LVDbVar[1-9]
  LVDbVar1           VGExaDb -wi-ao----  10.00g
  LVDbVar2           VGExaDb -wi-a-----  10.00g

Conclusão

Após a correção acima, uma nova execução do patchmgr não apresentou mais falhas pelo mesmo erro. A estratégia acima pode ser seguida em cenários de expanção normal do ambiente, onde sempre que for expandir o volume ativo, garantir que o volume inativo seja expandido com a mesma proporção.