2016-08-02 9 views
0

毎日のcronジョブを実行するサーバーを維持して、データソースを集約し、専用のRuby on Railsアプリケーションでアクセス可能なレポートを生成します。ライブリモートMySQLデータベースのローカル読み取り専用コピーを維持する効率的な方法は何ですか?

私たちのデータソースの1つは、パートナーのデータベースの部分ダンプです。パートナーはアクティブなアプリケーションを実行し、MySQL DBには数百のテーブルがあります。彼らは、アプリケーションDBの比較的低電力の読み取り専用スレーブに読み取り専用アクセスを許可しています。

スレーブDBのレイテンシの問題とパフォーマンスのボトルネックが原因で、DBのローカルコピーが限られています。レポートには約20のテーブルしか必要ないので、それらのテーブルをダンプするだけです。また、データは毎日の細分性だけで済みますので、リアルタイムの同期は必須条件ではありません。

数ヶ月間、私は夜間に必要なテーブルのダンプをローカルのproduction_tmpデータベースにストリーミングしました。その後、すべてのテーブルがインポートされたら、私はproductionをドロップし、production_tmpproductionにリネームしました。 DBが25GB以上になるまでこれは動作していましたが、ディスク容量の制限がありました。

今のところ、私は冗長性のステップを削除して、ダンプをローカルサーバのproductionに直接ストリーミングしています。これは私にとってはちょっと気味が悪く、より安全なアプローチを実装したいと考えています。また、現在のところ、フルダンプ/ロードを行うのは2時間以上かかるため、時間がかかりません。データベースは成長を続けるだけなので、将来の何かを実装したいと思います。

ご意見をお寄せください。

+0

は、あなたは、MySQLの 'ホットbackup'機能を使用してみましたか?この転送を行うためにDB全体をダンプするように思えますが、実際には変更のみを移動する必要があります。詳細情報:[増分バックアップ](http://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_incremental_backup) –

+0

@SusannahPottsはMySQL Enterprise Editionでそれを行う唯一の方法ですか? –

+0

私はそう信じています... MySQLは有償版の機能性についてかなり厳しいです。私はあなたがMySQLのライセンスは商用利用を許可していないと見てEEのバージョンを使用すると仮定していた...少なくとも私が読んだライセンスのビットから。 –

答えて

2

私はそれを聞いたことがないか、またはMySQL Replicationと考えていますか?

あなたはバックアップ&を一度復元してから、レプリカをプライマリMySQLインスタンスで行われたように継続的な変更ストリームに「購読する」ように設定するという考え方があります。プライマリに適用された変更は、数秒で自動的にレプリカに適用されます。レプリカが破損していない限り、バックアップの&復元手順を再度実行する必要はありません。

セットアップには注意が必要ですが、2つのインスタンスを同期させる方がはるかに効率的な方法です。


@SusannahPottsは、ホットバックアップおよび/または増分バックアップについて言及しています。 Percona XtraBackupを使用してMySQL Enterpriseを支払うことなく、これらの機能を無料で利用できます。

また、MySQL Transportable Tablespacesの使用を検討することもできます。


Percona XtraBackupまたはMySQL Enterprise Backupを実行するには、ファイルシステムにアクセスする必要があります。たとえば、Amazon RDSの物理バックアップツールを使用することはできません。

もう1つの方法は、ライブシステムと同じネットワークに複製スレーブを作成し、そのスレーブ上でPercona XtraBackupを実行することです。ここでファイルシステムにアクセスできます。

もう1つの方法は、バイナリログを別のホストにストリーミングして(https://dev.mysql.com/doc/refman/5.6/en/mysqlbinlog-backup.html参照)、定期的にローカルインスタンスに転送して再生することです。

これらのソリューションにはそれぞれ長所と短所があります。要件について完全な詳細を共有していないため、どのソリューションが最適かをお勧めするのは難しいです。

+0

混乱する必要はありません。私は複製に精通していますが、それが既にスレーブであるリモートDBのsync'ingのための最良の選択であるかどうかはわかりません。おそらく、私がスレーブを削除する唯一のアクセスは、MySQL専用のSSHトンネル経由であることにも注意してください。 –

+1

私の答えは納得しないようにしてください。それは私の意図ではありません。あなたの質問には、複製オプションについて知っていることは何もありません。多くの人々はしません。 –

+0

Percona XtraBackupは探索するのに適しています。リモートサーバ上でファイルシステムにアクセスできるのであれば、トランスポータブルテーブルスペースは良いでしょうが、そうではありません。 –

1

DBが25GBを超えるまで動作していましたが、ディスク容量の制限がありました。

「ここで」一部の疑問符:

  • あなたは自分のデータベースで使用できるディスク容量を増加させないのはなぜ?ディスクスペースになると25 GBは何も見えませんか?
  • スクリプトを変更してtable1をインポートし、table1_tmpをインポートし、table1_prodを削除し、table1_tmpの名前をtable1_prodに変更してください。リンスとリピート。それ以外

  • は、なぜあなたは上でレポートを実行するのに十分な性能を備えたシステムのためのあなたのパートナーを求めませんか?私は確信している、彼はあなたの "ローカルサイト"に毎日機密データをダウンロードするよりも、これを好むだろうか?

最後に考えたのは(MySQLのエンタープライズバックアップhttps://www.mysql.de/products/enterprise/backup.htmlが必要です):

  • のではなく、毎日25ギガバイトを、ダンプのダウンロードとインポート:
  • フルバックアップ
  • ダウンロードを作成し、
  • をインポート今から差分バックアップまたは増分バックアップを使用してください。
  • あなたがダウンロード(およびインポート)次の日だけのデータ・デルタ:https://dev.mysql.com/doc/mysql-enterprise-backup/4.0/en/mysqlbackup.incremental.html
+1

良いおすすめ。最初の2つの点を見ると、DBを柔軟なブロックストレージボリュームに移動しました。また、スクリプトをテーブルごとに同期するように変更しました。これにより、同期に必要なディスクのオーバーヘッドが大幅に削減されます。提案していただきありがとうございます! –

+0

@HunterBridgesようこそ。 – dognose

関連する問題