大規模サイトのデータベースアーキテクチャを最適化する方法は?


28

質問は、特定のMysql構成アイテムに関するものではなく、複数のデータベースの処理、複数のデータベースサーバーへの読み取りと書き込みの分割、master + masterに関するものですか?マスター+複数のスレーブ?

人々はどのような経験をしましたか?これを達成する方法の例はありますか?

回答:


18

MySQLクラスターの経験はかなり豊富です。また、Perconaは、複雑な構成の境界を押し広げる際に何度も協力してきました。

Magentoはネイティブで読み取り専用スレーブを処理できます

Magento 、さまざまなデータベースサーバーへの読み取り/書き込みをネイティブに分割できます(EE 1.11などのいくつかの壊れたリリースを除く)- select追加(またはそれ以上)のサーバーへの負荷を相殺できます。すべてのupdate/writeクエリを単一のマスターに転送します。

いつすべきですか

これはより適切な質問です。MageStackのような専用のMagentoオペレーティングシステムでは、組み込みのサーバー側の高度なキャッシング技術が利用可能になり、簡単に使用できるようになりつつあります(VarnishフロントエンドキャッシングやRedisバックエンドキャッシングなど)。

歴史的に、MagentoはMySQLに拘束されたことはありませんが、PHPに拘束されました。しかし、ワニスとフルページキャッシュ(FPC)がより頻繁に使用されると、繰り返されるタスク(カテゴリ/製品のロード、頻繁な検索)の負担が突然吸収され、PHPの負担が軽減されます。実際、最初にコンテンツを生成するか、キャッシュ不可のシナリオ(カートへの追加、注文完了など)を完了するためにのみ実際に使用されます。説明のために管理負荷を故意に無視しています

ここここの両方見られるように、MySQLはほとんどの小売業者にとって関心のある分野ではないという事実を常に守ってきました。しかし、1桁または2桁ではなく、1時間あたり数百件の注文を処理する地域にいる場合、すぐに最適化の領域になります。

最終的に小規模な店舗向け(1日あたり25,000未満のユニークビジター)

あなたの努力は、オフセットから適切なハードウェアを提案できる適切なホストを見つけることと、お店に最適な方法マシンを構成することに単に焦点を当てることになります。マスター/スレーブまたはマスター/マスター構成の追求に時間を浪費しないでください。パフォーマンスの利点は得られず、最終的には継続的な注意と高度なMySQL知識が必要になります。

最終的に、ハードウェアのサイジングと選択は、MySQLの最適化よりも大きな役割を果たします。

しかし、大型店の場合

ストアが成長し始めると、変換またはトランザクションの負荷は、複雑なタスクを完了するという繰り返しのタスクの負担にinsertsなりupdatesます。新しい注文が追加されるたびに、カタログ在庫の減少、支払いゲートウェイからのコールバック、EPOS / ERPシステムからの更新がトリガーされます。これをそれぞれの製品/カテゴリの関連するキャッシュパージと組み合わせると、MySQLの負荷が不均衡に増加することがすぐにわかります。

マルチマスターは実行可能なオプションとして推奨または検討するソリューションではありませんが、マスター/スレーブは読み取り負荷をセカンダリ/ターシャリノードに相殺することでメリットをもたらします(エンタープライズサイズのストアで重視します)。

でもまだやりたい

最初にスレーブを構成します。私たちはPerconaユーティリティとMySQLブランチの大支持者です。既存のDBのホットバックアップ(innobackupex)を作成するための理想的なツールがあります。ここに良い記事があります

マスターに

$ TIMESTAMPまたはタブ補完を置き換えます。

mysql
> GRANT REPLICATION SLAVE ON *.*  TO 'repl'@'$slaveip' IDENTIFIED BY '$slavepass';
> quit;
innobackupex --user=username --password=password /path/to/backupdir
innobackupex --user=username --password=password /
       --apply-log /path/to/backupdir/$TIMESTAMP/

rsync -avprP -e ssh /path/to/backupdir/$TIMESTAMP TheSlave:/path/to/mysql/
scp /etc/mysql/my.cnf TheSlave:/etc/mysql/my.cnf

奴隷に

/etc/init.d/mysql stop
mv /path/to/mysql/datadir /path/to/mysql/datadir_bak
mv /path/to/mysql/$TIMESTAMP /path/to/mysql/datadir
chown -R mysql:mysql /path/to/mysql/datadir
sed -i 's#server-id=1#server-id=2#g' /etc/mysql/my.cnf
/etc/init.d/mysql start
cat /var/lib/mysql/xtrabackup_binlog_info
> TheMaster-bin.000001     481

mysql
> CHANGE MASTER TO MASTER_HOST='$masterip', MASTER_USER='repl', MASTER_PASSWORD='$slavepass', MASTER_LOG_FILE='TheMaster-bin.000001', MASTER_LOG_POS=481;
> START SLAVE;

その後、実際にスレーブが動作可能になると、わずか数行のコードを追加するだけで実現できます。

./app/etc/local.xml

<default_read>
  <connection>
    <use/>
    <host><![CDATA[host]]></host>
    <username><![CDATA[username]]></username>
    <password><![CDATA[password]]></password>
    <dbname><![CDATA[dbname]]></dbname>
    <type>pdo_mysql</type>
    <model>mysql4</model>
    <initStatements>SET NAMES utf8</initStatements>
    <active>1</active>
  </connection>
</default_read>

ソース


「歴史的に、MagentoはMySQLに縛られたことはありませんが、PHPに縛られています。」あなたが何を言っているのかはわかりませんが、EAVは常にパフォーマンスの問題でした。:)
B00MER

1
まあ、私たちが管理している400以上のMagentoサーバーについて言及しています...大多数のルールとして、MySQLが考慮される前に他の多くのボトルネックがあります。実際、12月の顧客の1つがその好例です。1時間あたり15,000人のユニークビジターで、1台のサーバー(32コア、64GB RAM)で1時間あたり200件の注文を処理します。この質問の典型的な読者にとって、彼らはこのボリュームさえすることは非常にありそうにありません。そのため、トラフィックとトランザクションのレベルでは、MySQLはボトルネックではありません。
ベン・レッサーニ-ソナシ

1
@ブランドン。追加するだけです。MySQLのチューニングが要件ではないことは否定しません。明らかにそうです。しかし、実際に特定の転換点に到達するまで、パフォーマンスを改善するためにマスター/マスターまたはマスター/スレーブのセットアップを構成する必要はありません-それはかなり高いです。また、パフォーマンスのボトルネックを引き起こしたり、データの整合性を危険にさらしたりする可能性が非常に高くなります。
ベン・レッサーニ-ソナシ

5

一般に、MagentoはデータベースにバインドされているのではなくCPUにバインドされており、ほとんどのCPUアクティビティをキャッシュすることができるため、ニス/ nginxのセットアップに関するチュートリアルが多数あります。こちらで説明するように、管理者を別のwebnodeに移動することもできます

一般的な堅牢性を確保するために、バックの絶対的な最高の価値はマネージドMySQLサービスになります。

私はAmazon RDSの経験しかありませんが、フェイルオーバー、バックアップ、アップグレード、スケールアップ/スケールダウン、およびリードレプリカの作成を自動化します。したがって、自動フェイルオーバーを備えた高可用性マスターノードを使用できます-Amazonは、スレーブの同期を保つためにカスタマイズされたバイナリログレプリケーションを使用し、フェイルオーバーは通常2分未満で完了し、その後、必要な数のリードレプリカを作成できますレポート/統合のニーズに合わせてスケールアウトする必要があります。

Magentoのアーキテクチャでは非常に実行可能な読み取り/書き込みの分割を検討しましたが、データベースは私のユースケースのボトルネックではありません。最適化する必要があるものを推測するのではなく、xhprof / xhguiのようなプロファイリングを利用することを強くお勧めします。プロファイリングの最初のルールは測定することです。


質問にリンクで回答するブックマークWebサイトを構築するためにここにいるのではありません。回答の重要な部分をここに含め、参照用のリンクを提供してください。
j0k

@ j0kリンクは参照用に提供されており、答えはそれだけで成り立っています。同意できない場合は、より具体的にご記入ください。
ラルフ・タイス

はい、少なくとも、あなたの答えは他の答えよりも優れています。つまり、OPには、構成するもの、アーキテクチャスキーマではない理由などについて、より技術的なものが必要になる場合があります。
j0k

5

私はこれについての制作経験はありませんでしたが、掘り下げた後、この記事を見つけました。この記事では、Magentoのマスタースレーブレプリケーションのセットアップ方法について説明します。

最も重要なビット:

/app/etc/local.xml

<default_setup>
    <connection>
        <host><![CDATA[Master-host]]></host>
        <username><![CDATA[user]]></username>
        <password><![CDATA[pass]]></password>
        <dbname><![CDATA[magentodb]]></dbname>
        <active>1</active>
    </connection>
</default_setup>
<default_read>
    <connection>
        <use/>
        <host><![CDATA[Slave-host]]></host>
        <username><![CDATA[user]]></username>
        <password><![CDATA[pass]]></password>
        <dbname><![CDATA[magento]]></dbname>
        <type>pdo_mysql</type>
        <model>mysql4</model>
        <initStatements>SET NAMES utf8</initStatements>
        <active>1</active>
    </connection>
</default_read> 

マスターMySQLサーバー(/etc/mysql/my.cnf)の構成は、ファイルに以下の内容を追加します。

[mysqld]
server-id       = 1
log_bin         = /var/log/mysql/mysql-bin.log
expire_logs_days    = 10
max_binlog_size     = 100M
binlog_do_db        = magento_demo
binlog_ignore_db    = mysql 

スレーブMySQLサーバー(/etc/mysql/my.cnf)の構成は、ファイルに以下の内容を追加します。

[mysqld]
server-id=2
log-bin=mysql-bin
master-host=192.168.1.2
master-user=username
master-password=111111
master-port=3306
replicate-do-db=magento_demo
replicate-ignore-db=mysql
master-connect-retry=60 

その後、両方のMySQLサーバーを再起動します


1
それ自体が無意味であり、目標リソースが将来生きていることが保証されないので孤独なリンクは貧しい答え考えられます。ここに回答の重要な部分を含め、参照用のリンクを提供することが望ましいでしょう
j0k

@ j0k、要求どおりに完了;)
ケニー

3

1つのアイデアは、dns round-robinを使用してカタログ読み取りをスレーブサーバーに分割できるということです。

したがって、MySQLで通常のマスター->スレーブ複製をセットアップします。

その後、Magentoのセットアップで、ラウンドロビン構成のDNSホストからの読み取りを行うようにカタログを構成できます。書き込みはmasterデータベースに残ります。

あなたはこれをすることができます app/etc/local.xml

<catalog_read_setup>
   <connection>
      <host><![CDATA[round.robbin.dns.host]]></host>
      <username><![CDATA[USERNAME]]></username>
      <password><![CDATA[password]]></password>
      <dbname><![CDATA[DATABASE]]></dbname>
      <initStatements><![CDATA[SET NAMES utf8]]></initStatements>
      <model><![CDATA[mysql4]]></model>
      <type><![CDATA[pdo_mysql]]></type>
      <pdoType><![CDATA[]]></pdoType>
      <active>1</active>
   </connection>
</catalog_read_setup>
<catalog_read>
   <connection>
     <use>catalog_read_setup</use>
   </connection>
 </catalog_read>

コア(およびサードパーティ)モジュールをリダイレクトして、同じ方法で別のMySQLインスタンスを使用できます。


1
DNSラウンドロビンは、いかなる種類のソリューションでもありません。MySQLプロキシまたはHAProxyは、MySQLの読み込み負荷を分散するためのはるかに洗練されたソリューションです。
ベン・レッサーニ-ソナシ
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.