RHEL8/Oracle Linux8のmariadbでバイナリログを有効にする方法

RHEL8/Oracle Linux 8のmariadbをバックアップソフトでオンラインバックアップする場合、バイナリログを有効にする必要がある。

MySQL MySQL 5.7 Reference Manual「2.5.10 Managing MySQL Server with systemd
Oracle MySQL 8.0 リファレンスマニュアル「2.5.9 systemd を使用した MySQL Server の管理
RHEL8 さまざまな種類のサーバーのデプロイメント第9章 データベースサーバー「9.2. MariaDB の使用
MariaDB Administration「Starting and Stopping MariaDB » systemd

設定ファイルを書かずに、いまだけバイナリログで有効にして起動させる場合は以下となる。

# systemctl show-environment 
# systemctl set-environment MYSQLD_OPTS="--log-bin"
# systemctl restart mariadb
#

起動時から有効にする手法について確認すると /lib/systemd/system/mariadb@.service に /etc/systemd/system/mariadb@.service.d/MY_SPECIAL.conf に書くという記述があったので設定してみたものの読み込まれる気配がない。

いろいろ試した結果、/etc/systemd/system/mariadb.service.d/ファイル名.conf でファイルを置いた場合に動作するということが分かった。

# vi /etc/systemd/system/mariadb.service.d/override.conf
# cat /etc/systemd/system/mariadb.service.d/override.conf
[Service]
Environment="MYSQLD_OPTS=--log-bin"
# systemctl daemon-reload
# systemctl restart mariadb
#

ファイルを編集したあとは、daemon-reloadを実行する必要があった。

なお、 /etc/default/mysql, /etc/default/mysqld, /etc/sysconfig/mysql にて「MYSQLD_OPTS=”–log-bin”」を設定する、という手法も実験してみたが、これらは動作しなかった。

Commvault バックアップのLinuxクライアントをインストールする場合の設定

2024/01/23現在 のLinuxクライアントとして設定する場合の要点

「gzip」と「tar」コマンドが利用できること。使えない場合は、パッケージをインストールする。

RHEL8/RHEL9系の最小インストールの場合、tarコマンドが使えないので注意。

クライアント側のFirewall設定は ポート 8400 をあけておくこと。

ポート8400を使った通信は、CommServeだけではなく、MediaAgentからも行われるので、IPアドレス制限をかける場合は注意すること。

なお、ポート8400をあけていなくても、クライアント上で起動したCommvaultのエージェントからCommServeなどへの通信が行えるが、内部的にリトライエラーを繰り返した代替策となるため処理に時間がかかるので推奨はしない。


2025/02/07メモ

11.38のLinuxのMediaAgentをAlmaLinux 9環境にインストールした際、「ports: 8403/tcp 8401/tcp 8400/tcp」の設定が追加されていた。あと、tarインストールしてないと無言で失敗するのは同じだった。


2023/10/10現在

Commvault 2022E(11.28)でLinuxクライアントをインストールする場合のメモ

System Requirements for Linux File System」には特に必要なパッケージについての記載は、RHEL/CentOS 7.1環境でnet-toolsをインストールしておくこと、以外の記載はない。

AlmaLinux 8.8の最小インストール環境で net-toolsが含まれていない状態ですが、この状態でCommvault 11.28.56環境でインストールを試みたところ、net-toolsがない状態でもインストールは成功しました。

また、tarコマンド、gzipコマンドについては必須ですが、Linuxの設定状況によってはtarコマンドがインストールされていないことがあるのでが「tarコマンドがない」的なエラーはでないで失敗するので、原因が分かりにくいです。(エラーでた後に該当Linuxサにログインすると /opt/seed/ にファイルが転送されています。/opt/seed/cvpkgadd を実行してみると、tarコマンドがない、というエラーがでるので、ようやくわかります)

エラーコード: [68:184]

説明: Failed to install File System Core Package on client.
Source: linuxserver110, Process: DistributeSoftware

firewallについてはポートを開けない状態でもうまく動作する場合がおおかったですが、Media Agent/Virtual Server設定などを行った際には、ポートを開けておかないと動作が安定しませんでした。

加えて、インストールしてそのまま使うだけであればfirewall設定をしないままでも通信に成功し、バックアップの取得も可能でしたが、一度再起動すると接続が確立しない状態となりましたので、ポートは開けておくべきです。

また、VMware Proxy/Access Nodeとした場合、 https アクセスも必要であったようでしたので下記の例ではport 8400と、port 443(https)を追加しています。
MAの場合は追加で port 50000-50020 とかしておいた方がよさそうです。

普通のLinuxクライアントとして使う場合は port 8400だけで大丈夫でしょう。

# firewall-cmd --permanent --zone=public --add-port=8400/tcp
success
# firewall-cmd --permanent --zone=public --add-service=https
success
# firewall-cmd --reload
success
# firewall-cmd --list-all
public (active)
  target: default
  icmp-block-inversion: no
  interfaces: ens192
  sources:
  services: cockpit dhcpv6-client https ssh
  ports: 8400/tcp 
  protocols:
  forward: no
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:
#

また、Linux仮想マシン内の個別ファイルをリストアする際に利用するFREL仮想マシン(File Recovery Enablers for Linux)は、通常のLinux MediaAgent+Virtual Server構成では使えません。

追加設定として「Converting a Linux MediaAgent to a File Recovery Enabler (FREL)」にある設定を行う必要があります。

また、FRELは/opt/commvault/CVBLK 以下にあるコンパイル済みのkernel module cvblk を使用します。ここに該当のkernelバージョンのモジュールがない場合はFRELに昇格できません。

また、VSAとして使う場合に、Commvault環境を一時的なNFSサーバとしてvSphere環境からデータストアとしてマウントし、バックアップされているvmdkファイルを使う、という3dnfs serviceを使う場合は、追加でNFS v3で必要なポート設定をする必要があります。

こちらについては面倒なので「Additional Port Requirements for 3dnfs Services」を参照のこと…というか、そこまでやるならfirewallをoffにした方が早いですけどね。FREL仮想マシンはfirewall offですし。

2023/10/18追記

Commvault 2023E(11.32)環境にテスト環境を作った
(1)CommServe単独サーバ Windows
(2)MediaAgent+重複排除のバックアップ保存領域 Windows
(3)IndexServer Windows
(4)VSA/FREL Linuxサーバ

(1),(2),(3)のWindowsサーバで共通のfirewall設定「Windows Management Instrumentation (DCOM受信)」「Windows Management Instrumentation (WMI受信)」「ファイルとプリンターの共有」を有効化と、Commvaultがインストール時に自動作成するルールの有効化

Linux仮想マシン内の単独ファイルをリストアするためにブラウズする際は、(2)から(4)のport 8403に対して通信が発生し、(4)側で8403を開けていないと失敗した

(1)CommServeは動作中のcvfwd.log を見ると、8400~8403 を開けておいた方が接続が早そう。

(2)MAは8400,8403 をあけた方が良い。NDMPバックアップを保存する場合は10000と50000-50050 とMAのネットワークルート設定のインカミングに50000-50050を追加


2021/5/24 に書いたもの

CommvaultバックアップのLinuxクライアントをインストールする際にうまく行かずに悩んだ点が発生したのでメモ書き。

Linux File System Agent: System Requirements」には下記のような記述があるが、実際にはRHEL/CentOS 7.1以外でも発生する問題である。

Net-tools Package
On Red Hat Enterprise Linux/CentOS 7.1 computers, make sure to install the net-tools package.

それどころか、RHEL8/CentOS8などでは、tarパッケージが最小インストールではインストールされなくなっているため、インストールに失敗する。(vSphere環境上にインストールする場合、open-vm-toolsの必須パッケージとしてtarがインストールされるため気がつきにくい)

今回、RHEL8.3, AlmaLinux 8.3, Rocky Linux 8.3, openEuler 21.03, CentOS 7, Ubuntu 18.04にインストールした結果、必要だったものは以下であった。

・必須のコマンド
tar, netstat, gzip コマンド
・上記が含まれるパッケージ(RHEL系の場合)
tar net-tools

また、firewalld/iptablesによる通信制限がかけられている場合、下記を実行してポートをあけた方が良い。

ただ、あけなくてもバックアップできる場合もある。

現状を確認「firewall-cmd –list-all」

[root@centos8 ~]# firewall-cmd --list-all
public (active)
  target: default
  icmp-block-inversion: no
  interfaces: ens192
  sources:
  services: dhcpv6-client ssh
  ports:
  protocols:
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:
[root@centos8 ~]#

Commvault用にポート8400をあける設定

[root@centos8 ~]# firewall-cmd --permanent --zone=public --add-port=8400/tcp
success
[root@centos8 ~]#

設定の反映

[root@centos8 ~]# firewall-cmd --reload
success
[root@centos8 ~]#

反映されたことを確認

[root@centos8 ~]# firewall-cmd --list-all
public (active)
  target: default
  icmp-block-inversion: no
  interfaces: ens192
  sources:
  services: dhcpv6-client ssh
  ports: 8400/tcp
  protocols:
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:
[root@centos8 ~]#

また、rootユーザでのログインが禁止されている場合は、以下の4つの手段のどれかを使う

その1) 予め各Linuxサーバの/etc/sudoers ファイルにインストール用ユーザを設定してリモートインストールを行う「Adding sudo Users with Root Privileges on a UNIX Client

その2) 各LinuxサーバにLinuxクライアントパッケージを転送してrootユーザでインストールを行う「Installing Commvault Locally on UNIX, Linux, and Macintosh Computers Using the Installation Package

その3) 各LinuxサーバにLinuxクライアントパッケージを転送して一般ユーザ+sudoでインストールを行う「Installation of UNIX Agents by a Non-Root User

その4) 各Linuxサーバでrootログインを許可する

Commvaultの自働スケジュールの動きを確認した

CommVaultにはフルバックアップと増分バックアップをバックアップサーバ上で論理合成して新しいフルバックアップにする、という合成バックアップ(Synthetic Full)という仕組みがある。

V11SP16より前までは増分バックアップを実行した後に続けて合成処理を行う、というスケジュールを作成することができたが、2021年の現在ではそのようなスケジュールを作成することはできず、増分とは別に合成バックアップ用のスケジュールを作成する必要がある。(参考)

問題となるのは増分バックアップの終了時間にあわせて合成バックアップを実行する、ということが難しい、ということ。

単純に増分を毎日0:00開始、合成フルバックアップを日曜12:00開始、とかに設定した場合、増分バックアップに12時間以上かかり、日曜12時もバックアップ中であった場合、同名のスケジュールが動作しているので合成処理がスキップされてしまうことになる。

ドキュメントをみると「自働」スケジュールを設定することを推奨されており、「週1回合成フルを実行する」としたい場合は「自働 7日」というスケジュールを実行することで、7日に1回実行されることになるようだ。

7日で検証すると時間がかかりすぎるので「自働 2日」を設定して検証してみた。

開始終了
合成フル2021/3/24 18:522021/3/24 19:00自働2日というスケジュールを18時半過ぎに設定
増分2021/3/25 3:002021/3/25 3:01
増分2021/3/26 3:002021/3/26 3:01
合成フル2021/3/26 19:172021/3/26 19:24前回の実行終了から48時間+17分で実行された
増分2021/3/27 3:002021/3/27 3:02
増分2021/3/28 3:002021/3/28 3:01
合成フル2021/3/28 19:432021/3/28 19:49前回の実行終了から48時間+19分で実行された
増分2021/3/29 3:002021/3/29 3:02
増分2021/3/29 20:102021/3/29 20:11開始時刻を20:10変更
合成フル2021/3/30 20:082021/3/30 20:14前回の実行終了から48時間+19分で実行された
増分2021/3/30 20:132021/3/30 20:18開始時刻を20:10したが、合成フルが動作していたので遅延?

実行するたびに時間が後ろにずれていくのが気になる・・・

この17分~19分はどこから来ているのかな?とスケジュール設定画面を見直してみると、「ファイルまたはログのアクティビティ検出頻度 0時間15分」という変更ができない項目がある。

これは、15分間隔で自動バックアップを実行するべきか判断する、ということになるんだろうか?

だとすればこの動きも納得かな、と


2021/04/05追記

合成バックアップが実施される予定の時間帯にシステムが停止していた場合、どうなるかを確認したところ、システム起動後に合成バックアップが実行されました。

NetBackupのバックアップポリシー名を変更する

Veritas NetBackupでバックアップポリシー名を変更しようと思ったら、GUIにそういった操作が見当たらない。

調べるとコマンド bppolicynew コマンド の-renameto オプションを使うと変更できる、とのこと。

bppolicynew 元のポリシー名 -renameto 新しいポリシー名

という単純なものではあるのですが、複数をいっぺんに変更するとなるとポシリー名を間違わずに入力するのが非常に面倒となる。

バックアップポリシー一覧はbppllist コマンドで出力できるのだが、こいつには検索機能がなく、全部出力か、指定した1つ出力しかなく非常に使いにくい。

特定のバックアップタイプとか、特定のクライアントとかの検索をしやすいようにPowerShellを使って成形することとした。

「bppllist -allpolicies」は人には読みにくい形式ですが、出力される各行についてマニュアル内に解説があるのでそれに従って情報を取得することとした。

今回使用するのは

・CLASS行「フィールド1:ポリシー名」
・INFO行「フィールド1:ポリシータイプ」13=Windows,19=NDMPなど
・INFO行「フィールド11:ポリシーの有効無効」0=有効,1=無効
・INFO行「フィールド19:ポリシーを有効にする日付」(マニュアルは18となってるけど)
・INFO行「フィールド20:クラスID」ポリシー固有のID(マニュアルは19となってるけど)
・CLIENT行「フィールド1:クライアント名」

1つのポリシーに複数のクライアントが設定されている場合、CLIENT行は複数出力されるが、今回の環境ではそのような設定をしていないため考慮していない。

$tempfile = New-TemporaryFile
Start-Process -FilePath "C:\Program Files\Veritas\NetBackup\bin\admincmd\bppllist.exe" -ArgumentList "-allpolicies" -Wait -PassThru -NoNewWindow -RedirectStandardOutput $tempfile

$policyname=""
$policyname2=""

Get-Content $tempfile |ForEach-Object {
    $linetext=$_
    if($linetext.Contains("CLASS ")){
        $policyname2=$policyname
        $policyname=$linetext.Split(" ")[1]
        if($policyname2 -ne ""){
            #Write-Host $policyname2 " " $policytype " " $policyactive " " $policyclassid " " $policyactivedate
            Write-Host $policyclient "`t" "bppolicynew" $policyname2 "-renameto" $policyname2
        }
    }elseif($linetext.Contains("INFO ")){
        $policytype=$linetext.Split(" ")[1]
        $policyactive=$linetext.Split(" ")[11]
        $policyactivedate=$linetext.Split(" ")[19]
        $policyclassid=$linetext.Split(" ")[20]
    }elseif($linetext.Contains("CLIENT ")){
        $policyclient=$linetext.Split(" ")[1]
    }
}
$policyname2=$policyname
#Write-Host $policyname2 " " $policytype " " $policyactive " " $policyclassid " " $policyactivedate
Write-Host "bppolicynew" $policyname2 "-renameto" $policyname2

# New-tempfileを使用している場合は削除を忘れない
Remove-Item -Path $tempfile

なお、powershell上でDOSコマンドを実行するにあたり、ファイル出力をしないで直接PowerShellのパイプ連携を実施しようとしたのだが、実現できなかった。

このため、「-RedirectStandardOutput」で一時ファイルに出力してから処理という形を取っている。

Backup ExecでNetAppのNDMPバックアップを行おうとしたときに0x20500106(542114054)というエラーになる

Backup ExecでNetAppのNDMPバックアップを行おうとしたときに0x20500106(542114054)というエラーになるという問題が発生した。

技術的詳細をみてみてもよく分からない。

該当の共有を確認すると日本語のディレクトリがある。

そして、NetApp上でボリュームの言語を確認するとja_JP.PCK_v2とUTF-8以外を使用している。

nas01c::> volume show -fields language
vserver   volume language
--------- ------ --------
<略>
svm1      testlang2
                 ja_JP.PCK_v2
nas01c::> 

では、日本語ではなく英数のディレクトリ名に変更

Backup Exec上で問題なく開くことができるようになった。

とりあえず、ボリュームの言語設定の問題であることは判明。

検索すると「How to enable Unicode or UTF-8 Language Support for the NDMP Option」というBackup Exec 11時代の古い記述を発見

ここに書かれている HKEY_LOCAL_MACHINE\SOFTWARE\Veritas\Backup Exec For Windows\Backup Exec\NDMP の UseUTF8の値は「0」であり、UTF-8じゃないボリュームという設定になっているように見える。

この値の変更は、NDMPアクセスをするごとに反映されるようでBackupExecサービスやサーバ再起動は不要だった。

が・・・今回のja_JP.PCK_v2ボリューム上の日本語ディレクトリ問題には対処できなかった。

では、この値変更はBackupExec 21.0で不要かというとそうではなくて、ja_JP.UTF-8ボリュームだと日本語ディレクトリが文字化けで表示される、という問題が発生している。

これが「UseUTF8」の値を「1」に設定することで文字化けが解消されることは確認できた。

さて、本題に戻って、ja_JP.PCK_v2ボリューム上に日本語ディレクトリがある場合にエラーとなる件の対処方法があるかです。

とりあえずボリューム名をクリックするとバックアップ選択はされ、バックアップも完了できました。(レジストリ UseUTF8は0で実施)

リストアを選択すると、きちんと日本語で表示されています。

共有内のファイルを削除してリストアしてみると、正常にリストアされました。

しかし、「実験」だけをリストアしようとするとエラーとなりました。

というわけで、ja_JP.PCK_v2上に日本語ディレクトリがあっても、ボリューム全体をバックアップするのであれば問題無く動作する。

リストア時も全体であればリストアが成功するが、日本語ディレクトリは個別に指定するリストアは失敗する、という動作となりました。

ちなみにja_JP.UTF-8ボリューム上の日本語ディレクトリは文字化けでした。(レジストリUseUTF8は0)

文字化けしている状態であっても、文字化けディレクトリだけを指定してリストアすると正常にリストアできていました。(レジストリUseUTF8は0)


逆にレジストリUseUTF8を1にしてバックアップしたものはリストアできるか検証

ja_JP.UTF-8ボリューム上の日本語は表示できているが、ja_JP.PCK_v2ボリューム上は文字化けています。

リストアジョブを実行してみると成功します。

ja_JP.UTF-8ボリュームではファイル名も問題無くリストアできています。

ja_JP.PCK2_v2の方は文字化けでリストアされています。

ややこしいことにディレクトリ内のファイルについては文字化けせずにリストアされています。

おそらく、指定した階層についてだけ影響があり、それ以下の階層についてはNetApp側で処理されるため元のファイル名のままリストアできたものと想定されます。