タグ付けされた質問 「replication」

レプリケーションは、信頼性、フォールトトレランス、およびアクセシビリティを向上させるために冗長ハードウェア/ソフトウェアリソース間の整合性を確保するために、あらゆるレベルの情報を共有するプロセスです。

1
レプリケーション環境でのビンログの削除
レプリケーション環境でのバイナリログの削除について質問があります。 1つのマスターと2つのスレーブがある環境があります(mysql 5.5を実行しています)。場合によっては、処理時間が長いときにスペースの問題が発生し、binログディレクトリがいっぱいになることがあります。ログは3日ごとに期限切れになります。私は、すべてのボックス(マスターと両方のスレーブ)でログを3日間保持する必要があるのか​​疑問に思っていました。たとえば、マスターでは3日間、スレーブでは1日間ログを保持するのは理にかなっていますか?それを行う最善の方法は何ですか? ありがとうございました!

1
テーブルを異なるデータベース名に複製する
私たちのQA環境には、データベース名に接尾辞「test」が付いています。たとえば、実稼働環境のdbname1には、対応するdbname1testがQAにあります。(これは、主にprod / qa構成が混同されるのを防ぐためです)。 実際の実稼働テーブルをQAに複製したいテーブルがいくつかあります。「dbname1からdbname1testにレプリケートする」と言うように指示する方法がわからない これも可能ですか?

5
同じ物理サーバーでレプリケーションを実行するのは賢明ではありませんか?
データベースのマスタースレーブレプリケーションのセットアップを検討しています。スレーブサーバーは冗長性のために使用され、場合によってはレポートサーバーとして使用されます。しかし、私が直面している最大の問題の1つは、データセンターのパワーがすでに限界に達していることです。そのため、別の物理サーバーを追加することはオプションではありません。 既存のデータベースサーバーは、CPUに関しては十分に活用されていません(クアッドコアで平均負荷が1を超えることはありません)。そのため、主要なアイデアは、いくつかの新しいドライブをトスし、メモリを2倍(8GBから16)にして、同じ物理マシンで2番目のmysqlインスタンスを実行することです。各インスタンスには、データベース用に個別のディスクがあります。 この考えに何か問題はありますか? 編集(詳細):私は(幸運にも)サーバーを停止するほど悪いことは一度もありませんでしたが、前もって計画しようとしています。もちろん、夜間にバックアップを作成して、そこから回復できます。ただし、マスターサーバーのドライブに障害が発生した場合(マシン全体が停止した場合は明らかにそうではない)、冗長データを別のディスクに保存すると、より迅速なソリューションが得られると考えました。 レポートの側面に関しては、レポートするテーブルはすべてMyIsamです。そのため、書き込み中の同じテーブルで高価な読み取りを行うと、サーバーが動かなくなる可能性があります。私の想定では、CPU負荷がまだ問題になっていないため、十分なRAMを投入する限り、スレーブサーバーがメインサーバーに影響を及ぼさないと報告していました。

1
SQL Server 2005からSQL Server 2012へのアップグレード
次のテスト環境をセットアップしています。 仮想マシン(Hyper-V) Windows Server 2008 R2 SP1(x64ビット) Windows SQL Server 2005 Developer Edition SP4(x64ビット)(デフォルトのインスタンス名) マージレプリケーションが設定された1つのデータベース...それぞれ2つのサブスクライバを持つ3つのパブリケーション。 SQL Server 2012 Developer Edition(sp1)へのアップグレード手順をテストしています... 64ビットSQL Server 2012開発用のisoをダウンロードしました。(sp1)MSDN(フルライセンスコピー)からアップグレードパスを開始しました。さまざまな基準のチェックを開始する最終段階の1つで、以下に概説する奇妙な問題に遭遇します。 Rule "Upgrade architecture mismatch" failed. The CPU architectures of upgrading feature(s) are different. To upgrade these features, Setup architecture must be the same as the features being …

2
MySQLの行ベースのレプリケーションとステートメントベースのレプリケーションの違いは?
行ベースのレプリケーションとステートメントベースのレプリケーションの実際の違いは何ですか。私は実際にスレーブへの複製の効果の観点から見ています。 行ベースのレプリケーションを使用している場合、スレーブにどのような影響がありますか。ステートメントベースのレプリケーションを使用している場合、どのような影響がありますか? 次のパラメータも考慮してください。 replicate-ignore-db and replicate-do-db ありがとう....!

3
スナップショットレプリケーションの保持
SQL Server 2008運用サーバーでスナップショットレプリケーションを設定しましたが、スナップショットフォルダーに1年前にまで遡るスナップショットがあることに気付きました。これらのスナップショットの保持を変更するにはどうすればよいですか?具体的には、スナップショットを5日間保持したいと思います。 これが私が見ているフォルダのスクリーンショットです:


3
MySQLレプリケーション-スレーブは継続的にマスターに遅れています
MySQL-5.1.50をマスター/スレーブレプリケーション設定で使用しています。 ほとんどの場合、スレーブはマスターより遅れています。 を実行してもshow processlist;、時間がかかるクエリはありません。私も有効にしslow_logました。ただし、実行速度の遅いクエリは検出されません。 スレーブはレプリケーションがマスターより数秒遅れていることを警告し続けています。時々、遅延時間が増加します。 問題の原因を診断するにはどうすればよいですか? この問題が過去20日間続いているため、緊急のサポートが必要です。

1
データチェックサムはストリーミングレプリケーションとどのように相互作用しますか?
データチェックサムは、9.3で導入された新機能であり、 新しいGUCパラメータ "ignore_checksum_failure"があり、破損が検出された場合でもPostgreSQLにトランザクションの処理を継続させます。 レプリケーションマスターでチェックサムエラーが発生した場合、破損したデータがスレーブにレプリケートされるか、レプリケーションが停止します。の設定に依存しignore_checksum_failureますか? この READMEには有用な関連情報がいくつかありますが、質問には直接回答しません。

1
SQL Serverスナップショットレプリケーションは毎回完全にデータをコピーしますか、それともデルタを発行しますか?
2つのサーバー間のスナップショットレプリケーションを見ています。これが私が持っているものです: 500GBデータベース 〜500MBの毎晩のbcpロード 〜50MBの毎日のトランザクション 使用するレプリケーションの種類について、社内の他のDBAに尋ねていました。スナップショットレプリケーションを使用するように言われました。ただし、私が理解して読んでいることから、ロード後の毎晩、スナップショットはデータベースをディストリビューターに完全にコピーし、他のサーバーを完全に上書きします。 スナップショットはデルタで機能しますか、それとも毎回完全なコピーですか?

2
公開された複製DBのDB互換性レベルを90から100に変更した場合の影響
現在、互換性レベル90(2005)で動作している一連の公開データベースを備えたSQL Server 2008 R2サーバーがあります。 サブスクリプションデータベースもSQL Server 2008 R2ですが、宛先データベースは互換性レベル100に設定されており、レプリケーションは正常に機能しています。 パブリッシュされたデータベースの互換性レベルを変更した場合、レプリケーションに何らかの影響がありますか、それともすべてのサブスクリプションを再初期化してレプリケーションを再開した場合だけでしょうか? パブリッシュされたデータベースの互換性レベルを変更すると、レプリケーションストアドプロシージャの機能が少し変わる可能性があると思いますが、100%確実ではありません。 これは事実ですか?

2
MySQLのSHOW SLAVE STATUSを理解しようとしています
マスタースレーブレプリケーションのセットアップを行っていますが、正常に動作しているようです。以下はSHOW SLAVE STATUSコマンドの結果です: show slave STATUS\G; *************************** 1. row *************************** Slave_IO_State: Waiting for master to send event Master_Host: *.*.*.* Master_User: repliV1 Master_Port: 3306 Connect_Retry: 60 Master_Log_File: mysql-bin.000001 Read_Master_Log_Pos: 10726644 Relay_Log_File: mysqld-relay-bin.000056 Relay_Log_Pos: 231871 Relay_Master_Log_File: mysql-bin.000001 Slave_IO_Running: Yes Slave_SQL_Running: Yes Replicate_Do_DB: data1 Replicate_Ignore_DB: Replicate_Do_Table: Replicate_Ignore_Table: Replicate_Wild_Do_Table: Replicate_Wild_Ignore_Table: Last_Errno: 0 Last_Error: Skip_Counter: …

2
SQL Serverレプリケーションを実装する時が来たことを示す客観的要因は何ですか?
データベースの高いパフォーマンスとメンテナンスの容易さのバランスをとろうとしています。レプリケーションを使用してパフォーマンスを向上させることを検討しています。SSRSレポートをトランザクションデータベースとは物理的に別のデータベースにレプリケートすることです。ただし、レプリケーションを有効にすることには、開発者の観点から多くの欠点があります。 スキーマの変更が困難になります 自動統合/ビルドサーバーを妨害する SQLソース管理の実装が難しくなっているようです 私の質問は次のとおりです。これらの欠点を考慮して、レプリケーションに移行する時期がいつになると思いますか 追加の複雑さが利益を正当化するかどうかをどのように決定しますか? 以前に使用したことがあるので、設定は問題ありません。これは、それを有効にするかどうかを決定することに関するものです。他の人がレプリケーションで観察したいくつかのオブジェクトパフォーマンスメトリックを探しています。 もちろん、最善のことは、私たち自身のサーバーでいくつかのシミュレートされた負荷テストを行い、それを自分で理解することですが、私はそこにいくつかの一般的なガイドラインがあることを望んでいます。

3
MySQLレプリケーションは高レイテンシの相互接続の影響を受けますか?
異なるデータセンターに常駐する標準的なマスターとスレーブのMySQLセットアップと、マスターと同じデータセンターにある別のスレーブがあります。 データセンター間の帯域幅はかなり高くなっていますが(ネットワークベンチマークでは、15MB /秒に達する可能性があります)、レイテンシが存在し、約28msです。決して高くはありませんが、同じデータセンターの1秒未満のレイテンシよりもはるかに高くなります。 ローカルスレーブが最新の状態であるときに、削除スレーブで重大な遅延(2000秒以上)が発生する場合があります。遅れているリモートスレーブを見ると、SQLスレッドは通常、IOスレッドがリレーログを更新するのを待つ時間を費やしています。マスターは同時に「ネットを待っている」またはある種の何かを示します。 つまり、それはネットワークであることを意味しますが、これが発生した時点ではまだ帯域幅に空きがあります。 私の質問は、データセンター間のレイテンシがレプリケーションのパフォーマンスに影響を与える可能性がありますか?スレーブioスレッドは、マスターが送信を停止するまでイベントをストリーミングするのですか、それともイベント間でマスターをプールするのですか?

3
マスターがオフラインになった場合、マスターMySQL DBをスレーブDBの変更とどのように再同期しますか?
MySQLサーバー1はマスターとして実行されています。 MySQLサーバー2はスレーブとして実行されています。 両方のDBがオンラインの場合、「完全に同期」しています。スレーブがオフラインになった場合でも、マスターがオンラインのままであれば問題はありません。スレーブが再びオンラインになると、同期が戻ります。 サーバー構成に加えて、マスターがオフラインになった場合、スレーブDBの接続を(JSPコードで)リダイレクトしました(もちろん、/ etc / init.d / mysqld stopでテストしました)。 マスターがオンラインに戻ったときに、マスターとスレーブの更新を自動的に同期する方法はありますか?

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.