私は、MySQL の論理バックアップと物理バックアップの両方を実行できるサービスの作成に取り組んでいます。論理バックアップは 4 時間ごとに実行され、物理バックアップは 1 日に 1 回、特定の時間に実行されます。どちらも、バックアップのベースとなる MySQL スレーブをシャットダウンする必要があります。また、同時に実行されないように処理する必要もあります。さらに、起動/再起動時に、最初の呼び出しではなく、実行されるべきではありません。
論理バックアップはmysqldumpS3 を使用してアップロードします。物理バックアップは EBS のスナップショットを取得します。
私は、両方が 1 分間隔で実行される単純なストレス ケース バージョンを実行しています。データベースは空で小さいです。EBS ボリュームは 1 GiB です。どちらも 1 分未満で実行できます。
ワンショットをトリガーするためにタイマー サービスを使用します。また、各タイマーをConflictsに相互に設定し、タイマーを に再定義しましたExecStopPost。
サービスファイルの例は次のようになります。それぞれが他のサービスを参照します。
[Unit]
After=mysql-slave.service
Conflicts=other-backup-type.timer
[Service]
Type=oneshot
# Just arbitrary name for this example
ExecStart=do_backup.sh
ExecStopPost=/bin/systemctl start other-backup-type.timer
私が見たところ、systemctl list-timers両方のタイマーは同期しています。両方が 0 になると、一方がトリガーされます。私が発見したのは、一度完了すると、もう一方はトリガーされないということです。この場合、タイマーは確かに停止しますが、もう一方のワンショットのトリガーは作成されないようです。
時間をオフセットせずにこれを適切に処理する方法はありますか? 期間をわずかにオフセットすると機能することがわかりました (秒は 60 の因数にはなりません)。これをサポートするより優れた/よりエレガントな方法があるかどうかを確認しています。
答え1
これが 100% 正しい答えかどうかは、よくわかりません。さまざまな組み合わせを試した結果、この答えにたどり着きました。
観察すると、2 つのタイマー (A と B) が設定されていてConflicts=、期限切れ時に別のタイマーと衝突する場合 (たとえば、両方とも 1 分ごとにトリガーするように設定されている場合)、トリガーするタイマー (A とします) が最初にもう 1 つのタイマーを停止し、次にそのタイマーのサービスをトリガーするようです。ただし、この停止により、タイマー B のサービスのトリガーが失われます。トリガーがキューから取り出され、停止のプロセスで破棄されるのではないかと推測しています。