データベースの継続的な展開を可能にするプラクティスまたはツールは何ですか？

インフラストラクチャとコードの継続的配信または継続的展開は、データベース、特にRDBMSに対して同じアプローチを試みるのに比べて比較的簡単です。コードとインフラストラクチャは、展開が完了しても変更も進化もしません。ただし、データベースには新しいデータが追加され、スキーマが本質的に可変コンポーネントでない場合、データが作成されます。

データベースオブジェクト、つまりテーブルと列のみを追加し、それらを変更または削除しないなどのプラクティスがあることを認識しています。スキーマ。

同様に、FlywayやReady Rollなど、スキーマのバージョン間で記述される移行の記述を支援する製品があります。

現在、データの整合性が懸念される本番環境へのデータベーススキーマの継続的な展開を可能にする他のプラクティスとツールはありますか？

Pramod SadalageとScott Amblerは、リファクタリングデータベース：進化的データベース設計という本を書きました。これは、CD組織/チームのDBの主題に対する非常に堅実な入門書です。

課題

データベースオブジェクト、つまりテーブルと列のみを追加し、それらを変更または削除しないというプラクティスがあることを認識しています

私が働いていたある会社で、生データのローリングウィンドウは約6か月に相当し、10 TBを消費しました。その後、データはRDBMS形式に処理され、6 TBの使用可能なデータがかかり、報告可能なデータの約10年間を占めました。重要なのは、これらの種類のプラクティスは大規模では、単に実用的ではないということです。ストレージは高価です-おそらく最大のコンピューティング費用。これには、いくつかの興味深い課題があります。

1. バックアップ -innodbプラグインは優れていますが、その量のデータのバックアップ時間はそれほど実用的ではありません
2. 復元時間 -大規模なデータセットの場合-特に、復元が動作状態に戻るまでに数日から数週間かかる場合があるため、レプリケーションが必要な場合
3. 新しいインスタンスの作成/シード -多くの場合、開発/テストで行う作業には、データセットのETL（抽出、変換、および読み込み）ジョブが含まれます。これらは、QAテストユニットを使用して検証する必要がありますが、元の実稼働データセットが保持されるように、非破壊的な方法でこれを行う必要があります。災害時には、バックアップは保険であり、それを回避することを目的としているため、DevOps開発ワークフローでは、基本的に、復元または定期的に（おそらく1日に複数回）データのコピー
4. 容量 -今説明した規模で大量のデータを処理することは、I / Oを集中的に使用する可能性があります。1-3で説明した問題に対処する必要があるだけでなく、運用システムの停止やパフォーマンスの低下を引き起こさない方法でそれを行う必要があります。

上記の考慮事項は小規模では問題にならないかもしれませんが、大規模ではこれらは大きな問題になります。つまり、要件を定義し、データセットのサイズを予測することが非常に重要です。

要件の定義

そのため、いくつかの要件を定義する必要があります。

1. RTO-バックアップのRTOまたは復元時間目標は、データベースバックアップソリューションの最も重要な要因の1つです。最初は、他のほとんどの問題に関連していないように見えるかもしれませんが、「新しいインスタンスを作成またはシードするためにバックアップソリューションを使用した場合はどうすればよいですか？」次のセクションでは、そのためのいくつかの手法について説明します。
2. RPO-バックアップのRPOまたは復元ポイントの目標は、A）どれくらい前まで復元できるか（分、時間、日、週、月、または年）B）さまざまな層でのバックアップ間隔とC）復元方法。たとえば、電子メールデータベースの場合、メッセージレベルのバックアップ（特定の電子メールの復元）がよく求められます。同様に、数日間のデータはまったく役に立たない場合があります。したがって、1年前に復元しても意味がありません。
3. データセットのサイズ -これは重要です。1MBのデータベースでは、ほとんどのバックアップ製品とソリューションでRTOを達成できるためです。しかし、10TBのデータベースに対しては、LTO 3テープへの完全な、行レベルのバックアップがあることでしょう、おそらくあなたのRTOを達成することはありませんし、バックアップは、バックアップウィンドウを超え始めるので、あなたのRPOを妨げる可能性があります。この大規模なデータセットでmysqldumpを正確に実行することはできませんが、おそらく1MBデータベースでmysqldumpを使用できます。
4. データベースの一貫性 - データベースを使用する際に、継続的な展開、サイトの信頼性、スケーラビリティ、および高可用性に大きな違いをもたらす最後のことは、一貫性の必要性（または不足）です。3つの基本タイプがあります：即時整合性、ジャストインタイム（JIT）整合性、および最終整合性

上記の主要な考慮事項に加えて、ライセンスとサポートの要件（オープンソースまたはクローズドソース、社内サポート、サードパーティのサポートまたはベンダーのサポート）のアプリケーション/言語要件（多くのデータベースのコネクタが重要になる可能性があります。あなたのアプリはコンパイルされていますか？ソースコードにアクセスできますか？それを再コンパイルできますか、それともベンダーから提供されますか？またはインタープリター言語で実行されますか？）政治的要件（あなたの組織はOracleだけを信頼していますか？ ？彼らはMySqlを信頼していませんか？MariaDBまたはPostgresについてどう思いますか？）およびデータベースエンジン（innoDB？MyISAM？Blackhole？NDB Cluster？Spider？）および歴史的または互換性の要件（私たちは何年もコードの半分でPL / SQLを使用しました） Oracleエンジンに組み込まれています！MariaDBにどのように移植できますか？！？）

これらのすべてが（かなり）使用可能なツールに影響します。

社内データ管理のオプション

注：以下は完全なものではありません。他のSEユーザーは、追加の提案を聞いてください。

汎用的な考慮事項を無視して、上記に対処するためのいくつかのテクニックとテクノロジーを提供します。まず、本当にRDBMSを使用する必要があるのか​​、Hadoop、CouchDB、またはObject Oriented Storage（swiftなど）のような非構造化データがオプションであるのかを自問してください。

第二に、クラウドベースのソリューションを検討することを検討してください。これは、この頭痛の種の一部を外部委託し、複雑な問題を有能な（そして有給の）個人に任せます。ただし、大規模な場合、これは予算に実際に食い込んでいることがわかります（クラウドプロバイダーはこれで利益を上げますが、特定の規模では、これらの専門家を自分で雇うだけの余裕があります）または特定のセキュリティまたは政治の下で働いている場合要件（読み取り：クラウドを実行できません）は、ハイブリッドNFS / FibreChannel Filerを検討します。NetApp、Pure Storage、Tegileなどのこれらのファイラーのほとんどは、A）バックアップの作成、B）バックアップの復元、C）新しいバックアップのシードに非常に便利なデルタベースのスナップショットとクローン作成の手法をサポートしています。

この時点で、私はバックアップとストレージの専門家ではないことに注意する必要があります。そのため、他の問題（および環境に優しい牧草地）に進む前に解決できなかったこの問題の一部があります。

ただし、これらの製品を使用すると、データベースの下で差分スナップショットを取得できます。データベースインスタンスの1つ（読み取り専用スレーブを推奨）で完全な「読み取りロック付きのロックテーブル」をスクリプト化して、binlog位置またはGTIDをダンプする必要がありますが、これらのファイラーについては、一度行うと、これらのスナップを使用して、データベースの新しいインスタンスを作成します。binlogを別のパーティションに配置し、データベースデータのみをこれらのパーティションに配置します。これを行うと、これらのパーティションのクローンを作成できます（NetAppでは、これは「FlexClone」として知られています）

これは、ブロックごとにファイラーがデータが凍結された元のスナップショットまたはデルタにあるかどうかを判断する必要があるためです。複数のスナップショットを持つボリューム/ストアの場合、これを複数回確認する必要がある場合があります。これを克服するには、データを更新します（つまり、スナップショットを破棄し、定期的に再度クローンします-これは、適切な継続的デプロイメント環境では自然かつ有機的に発生する可能性があります）または、ボリュームを永続的に分割する（NetApp用語では「Flex Split」と呼ばれます） ）デルタを恒久的に解決し、まったく新しい別個のボリュームを作成するには少し時間がかかります。

これらのデルタクローンには、全体的なストレージ要件を削減するという追加の利点があります。複数のクローンまたは実稼働データベースデータのインスタンスを生成して、開発、テスト、および検証を行うことができます。大規模なデータセットのコピーを1つだけに加えて（可能性が高い）小さなデルタのみを保持する場合、全体的なストレージコストとフットプリントを削減できます。

ここでの唯一の秘isは、「バックアップ」がファイラーに残っているため、これが完全バックアップソリューションを構成しない可能性があることです。そのためには、NetAppがSnap Mirrorと呼ぶものを使用して、ファイラーとデータセンター間でデータをミラーリングする（rsyncスタイルの技術を使用）か、デルタスナップショットの1つまたはフレックスクローン。

ただし、これには1つの大きな欠陥があります。すべてのデータ-dev、test、およびprodは、同じファイラーとストレージヘッドでI / Oをまだ使用しています。この問題を回避するには、2番目のファイラーにスレーブデータベースインスタンスを作成します。これは、テストファイラーまたはdevファイラーのシードポイントになるか、アプリケーションレイヤーのロードバランサー/アプリケーション配信コントローラーを使用して実稼働要求をミラーリングします。テスト（および/または開発）環境。これには、すぐに気付かない可能性のある問題を実稼働環境にプロモートする前に、QA /テスト環境で製品トラフィックをスローするという追加の利点があります。その後、本番トラフィックとユーザーの行動に基づいてログのエラーを確認できます。

これにより、いくつかのスクリプトを使用して、継続的な展開方法で使用するために（および大規模な）データセット全体をプログラムで生成および破棄できるようになります。

スケーラビリティと高可用性

継続的な展開についてお聞きしましたが、DevOpsは単なる継続的な展開以上のものであると考えられているため、冗長性、スケーラビリティ、高可用性について少し説明します。

私は、JIT、即時および最終的な一貫性について言及しました。これは、さまざまなRDBMSエンジンの出番です。循環非同期レプリケーションを構成するだけで、結果の一貫性は比較的簡単です。ただし、これにより衝突が発生する可能性があります*（レプリケーションが完了する前にアプリケーション層がクラスターの片側とクラスターの反対側のデータを更新した場合はどうなりますか？）即時の整合性については、同期レプリケーションを強制するGaleraクラスターをご覧くださいスケーラビリティの問題を引き起こします（ネットワークレイヤーでの伝搬遅延による大幅な遅延を発生させずに、地理的に災害復旧サイトに複製するか、負荷分散する方法）データセンター内で同期複製とサイト間の非同期複製を実行できるかどうかも確認できます。しかし、これは両方の世界の最悪のようです。

ただし、通常、ほとんどの人は完全な同期レプリケーションを必要としません。これは通常、テーブルシャーディングでマルチマスターが必要な非常に特殊な（そしてエキゾチックな）高書き込み環境にのみ必要です。ほとんどのアプリは、データベースプロキシを使用してJust-In-Timeの一貫性を処理できます。たとえば、ScaleArcはレプリケーションステータスを監視し、書き込みがどこに行ったのかを追跡して（レプリケーションが追いつくまで副次的な読み取り要求を送信するため）、ジャストインタイムの一貫性と外観を提供しますデータベースの一貫性。ScaleArcはPostgres、MySQL、MariaDB、Oracle、MSSQLと互換性があり、正規表現を使用して、シャードキーを使用できないアプリケーション用にデータベースをシャード/パーティション分割できます。また、構成管理ソフトウェアとやり取りするための堅牢なREST APIがあり、サポートチームは卓越しています

同様に、MariaDBチームがMariaDB用に開発したMaxScaleを無料で検討することもできます。ただし、GUIとScaleArcのキャッシュ機能の一部が欠けています。

最後に、MySQLファブリック（および、RAM内のMySQL Cluster-十分なRAMを購入できる場合）は、特にMySQLの新しいプロキシの場合、他の可能性もあります。これにより、環境にスケーラビリティと冗長性のコンポーネントを提供できます。

PostgresとOracleには必要なレプリケーションおよびシャーディング機能が必要ですが、プロキシが必要な場合はScaleArcはうまくペアリングします。

最終的に、クラウドベースの環境を単純に使用できず、クラウドプロバイダーが上記の問題に対処することができない場合、これらすべての要素は、継続的な展開と開発に適した柔軟性の高い環境になります。

アプリでPostgresスキーマを管理するために職場でFlywayを使用し、Cassandraスキーマを管理するためにPillarを使用します。アプリが独自のスキーマを管理する場合に最適です。

アプリが独自のスキーマを管理する前に、スキーマを管理できるという恐ろしい経験がありました。

スキーマの責任をアプリケーションチームに移さない限り、ツールだけでは実際には役に立たないと主張します。

当社は、利用くださいLiquiBaseをやフライウェイをアプリケーションチームがチェンジを作成する責任がある仕事、で。

これに加えて、純粋に相加的な方法を避けることができます。
各アプリケーションは、スキーマの変更が必要な場合、前のバージョンと互換性がある必要があります。その場合、アプリケーションはスキーマに新しい列を統合し、それに書き込み、前の列との間で読み書きします（同じデータを保持する前のバージョン）。
アプリケーションの次のバージョンでは古い列の更新を停止でき、現在使用されていない列を削除できるのは3番目のバージョンのみです。

明らかに、何かがうまくいかない場合には、定期的なバックアップが必要です。
本番環境で問題を回避するために統合テストで問題を引き起こす可能性のあるデータの適切なサブセットも良いアイデアです。理想的な場合は、実稼働データの匿名サブセットを取得します。

私たちは仕事でliquibaseを使用しています。QAツールQASymphonyでも使用されます。

内部でMSSQLおよびOracleデータベースに対して使用しており、QASymphonyはpostgres + mysqlインスタンスの両方で使用/使用しています。

メインフレーム環境のコンテキストで、およびDB2®データベースに固有のこの質問に答えるために、一般的に使用される（安価ではない）2つの選択肢があります。

• BMCのDB2®のオブジェクト管理。以下に詳細を示します（リンク先ページからの引用）：

  データベース内のオブジェクトに変更を加えるか、日常的な管理タスクを実行するだけでも、困難でリスクのある作業になる場合があります。追跡しなければならないタスクは数十ありますが、1つのミスステップが可用性とデータの整合性に悲惨な影響を与える可能性があります。DB2 11のBMC Object Administrationを使用すると、労力とリスクの両方を削減できます。これは、以下を支援するツールのコレクションです。

  • 複雑で異種のDB2環境の管理に必要な時間を短縮します。
  • 整合性を改善するために、アプリケーションのライフサイクル全体でルーチンタスクを自動化します。
  • 簡素化されたDB2カタログのナビゲーションと変更管理により生産性を向上させます。
  • 最小限の停止で変更とメンテナンスを実行することにより、アプリケーションの可用性を高めます。

• IBMのDB2 Administration Tool for z / OS。

  アプリケーションのライフサイクル全体でDB2オブジェクトとスキーマを安全に管理することに関連する複雑なタスクを簡素化し、可用性への影響を最小限に抑えます。

  • ユーザーがDB2カタログをすばやく簡単にナビゲートできるようにします
  • 正確なSQL構文を知らなくても動的SQLステートメントを構築して実行します
  • DB2オブジェクト定義に加えられた変更を管理および追跡して、実行前に潜在的な競合を解決します
  • データベースおよびテーブルに対して実行するDB2コマンドの構築を支援します
  • ユーザーがDB2オブジェクトを作成、変更、移行、ドロップ、リバースエンジニアリングできるようにします。
  • ユーティリティジョブをビルドおよび実行し、ユーザーがLISTDEFおよびTEMPLATEを活用して生産性を向上できるようにします

SCMツールとの統合

しばらく前に、SCMライフサイクル（SERENA ChangeMan ZMFが管理）でBMCの代替を実際に「統合」するように顧客から挑戦されました。このような統合の背後にある考え方は、「開発チームの特別なケースとしてDB2 DBAチーム（DDLを使用）を検討し、誤ってエキゾチックなエディター（BMCツール）を使用して移行するコード（DDL）を生成する」と考えています。

この統合に関する唯一の（しかし実際の）課題については、そのようなDBAツールの主要な利点の1つである「再起動性」も促進することでした。

• 再起動可能性とは、このDBAツールが（完了すべき作業の性質に応じて長時間実行されるジョブを介して）そのことを行っているときに、予期しないことが発生する可能性があることを意味します（デッドロック、時間の異常終了など）。

• これらのいずれかが発生し、バックアップから再起動したくない場合（開始前）、DBAツールは、問題が発生し始めた（チェック）ポイントから（およびどこから）再起動することを期待しますすべてを再実行する必要があります）。

• DBAツールの初心者がそのようなチェックポイントから再起動する方法を実際に知らず、単に（最初から）再試行すると、DBAツールは失敗します何らかの種類のユーザーエラーが発生します。そして、「最後の失敗の後にどうやって進めてほしいかを教えてくれるまで、私は何もすることを拒否します（事態をさらに悪化させないために）」。

• 結局、使用されているSCMツールにこの再起動機能を実装するための本当の手がかりには、SCMツールも調整する必要がありました。実際にそれがために使用することができるように失敗したSCMの手続きを再起動するだけではなくの...（典型的には、標的テスト/ PROD環境への配達に関連する）すべての繰り返し失敗したSCMの手続きを提出し、それらのSCMツールは、このような状況から回復する方法を一般的です（ ）。

ボーナス：BMC代替のSCM統合が完了した後、顧客はDBAツールをIBM代替に変更することを決定しました。そして、両方の選択肢は実際には同じようには見えませんが、SCM統合への影響はかなり小さいものでした。単に、IBMへの同等の呼び出しでBMC代替への呼び出しを（一部の再利用可能なSCMカスタマイズで）置き換えるだけです代替...（DevOpsの用語を使用して）feature-flags / feature-togglesによって実装されます。