問題タブ [backup-strategies]

私は最近、SQL Server 2005 から 2014 までのいくつかの SQL サーバーのデータベース管理を担当しました。ここでは、多くの DB が完全復旧モードになっていますが、適切な継続的なバックアップ メンテナンス プランはこれまでセットアップされていませんでした。

以前の DBA は、トランザクション ログ ファイルが制御不能になり、ハード ドライブがいっぱいになったときにのみ処理していたように思えます。だから私はこれを変更して、問題を完全に修正したいと思います。私はいくつかの本を読んでいて、何をする必要があるかについて十分に理解していると思うので、私の理解を検証し、まだ完全に理解していないいくつかの点を明確にするためにいくつかの質問をしたいと思います. .

そのため、これまでの私の理解に基づいて、完全バックアップから始まる保守計画を作成する必要があります。RTO や許容可能なデータ損失などを把握するために経営陣と話し合う必要があるため、この例では日曜日にフル バックアップを行うと仮定します。

次に、この保守計画に毎晩の差分バックアップを追加します...つまり、月曜日から土曜日までです。これは完全なバックアップであったり、より頻繁に差分を実行したりすることもあると思いますが、これは、私が物事を正しく理解していることを確認するための単なる例です。

次に、トランザクション ログのバックアップについてです。これらをバックアップし、ログ ファイルを切り捨てて、ログ ファイルが継続的に成長して制御不能になるのを防ぐ必要があることがわかりました。これをバックアップする頻度について具体的な推奨事項があるかどうかはわかりませんが、15 分が推奨されているのを見てきました。これは、許容可能なデータ損失ウィンドウにさらに収まると思います。あれは正しいですか？

私が発見したもう 1 つのことは、トランケーションを使用してトランザクション ログ ファイルをバックアップすると、ログ ファイルがすでに制御不能になっている場合、ファイルが縮小されないことです。また、これらのファイルを少なくとも定期的に圧縮するのは良くないことも読みました。一度圧縮すると、再び拡大する必要があり、断片化やパフォーマンスの問題が発生するからです。

今、私は現在、ファイルがすでに制御不能になっている状況にあるので、メンテナンスを行ったら、ログファイルを実際に一度縮小する必要があると思います。その仮定は正しいですか？

また、今回トランザクション ログ ファイルを縮小したら、ログ ファイルの縮小によるパフォーマンスの問題を回避するために実行する必要があるメンテナンス タスクはありますか?

私が疑問に思っていたもう 1 つの質問は、ポイント イン タイム リカバリに関するものです。たとえば、午前 5 時に完全バックアップを作成し、15 分ごとにトランザクション ログ バックアップを作成するとします。午前 6 時 18 分に何か問題が発生したというアラートが表示されます (テーブルが削除されたとしましょう)。したがって、午前 5:00 に発生したフル バックアップで復元し、それを NO RECOVERY モードのままにして、午前 5:15 から午前 6:15 までのすべてのトランザクション ログ バックアップを復元できることを知っていますが、ここに私が興味を持っているものがあります。で... DB が完全復旧モードになっているため、既存のトランザクション ログ ファイル (バックアップではない) を使用して、テーブルが削除される直前の 6:15 から 6:17 の間のすべてのトランザクションをロール フォワードすることはできますか? もしそうなら、あなたはこれをどのようにしますか？トランザクション ログ ファイルを含むハード ドライブを紛失した場合、これは明らかに機能しないと思います。

ありがとう

現在、HA postgresql アーキテクチャのストリーミング レプリケーションをセットアップする方法について調査を行っています。しかし、この問題は、一般的に混合環境でのバックアップ/復元およびメンテナンスにも関連しています。

「メイン」の postgresql サーバーは、Windows ボックスで実行されています。私は pg_dump を使用して毎日論理バックアップを作成し、pg_basebackup と WAL アーカイブを使用して PITR を提供する完全バックアップを作成しています (これはまだテストしていません)。

次のステップは、ストリーミング レプリケーションを介してレプリカを保持するスレーブ マシンをセットアップすることです。postgresql エコシステムのサポートが向上したため、この新しいホストは Ubuntu Server 16.04 LTS を実行しています。

1. pg_basebackup -h <main host> -D <datadirectory> --xlog-method=streamスレーブデータディレクトリを初期化しました。
2. 次に、テーブルスペース ファイルへのシンボリック リンクをいくつか修正する必要がありました。これは、これらが Linux ファイル システムではなく Windows パスを指していたためです。
3. standby_mode = on次に、connectioninfo を使用して recovery.conf ファイルを作成しました。
4. サーバーが構成されていることを確認hot_standby = onし、デーモンを開始しました

postgres が教えてくれるように、「データベース ロケール (明らかに Windows 固有の English_United_States.1252) はオペレーティング システムと互換性がありません」という問題が発生しています。

1252 は Windows 固有のロケールであり、Linux では en_US.UTF8 を使用する必要があることは承知していますが、このような混合環境では、次のようにする必要があります。

• Windows 上のメイン DB も en_US.UTF8 ロケールで初期化しますか?
• それは可能ですか？
• pg_basebackup フォーマットがオペレーティング システム固有である理由、またはそうでないバックアップ フォーマットがあるのはなぜですか?
• これを変換するために設定するコマンド ライン フラグはありますか?
• Linux のみ (または Windows のみ) を使用することも歓迎しますが、お客様が両方のオペレーティング システムにかなりの期間依存することになるのではないかと心配しています。