回答:
MySQLクラスターの経験はかなり豊富です。また、Perconaは、複雑な構成の境界を押し広げる際に何度も協力してきました。
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はデータベースにバインドされているのではなくCPUにバインドされており、ほとんどのCPUアクティビティをキャッシュすることができるため、ニス/ nginxのセットアップに関するチュートリアルが多数あります。こちらで説明するように、管理者を別のwebnodeに移動することもできます。
一般的な堅牢性を確保するために、バックの絶対的な最高の価値はマネージドMySQLサービスになります。
私はAmazon RDSの経験しかありませんが、フェイルオーバー、バックアップ、アップグレード、スケールアップ/スケールダウン、およびリードレプリカの作成を自動化します。したがって、自動フェイルオーバーを備えた高可用性マスターノードを使用できます-Amazonは、スレーブの同期を保つためにカスタマイズされたバイナリログレプリケーションを使用し、フェイルオーバーは通常2分未満で完了し、その後、必要な数のリードレプリカを作成できますレポート/統合のニーズに合わせてスケールアウトする必要があります。
Magentoのアーキテクチャでは非常に実行可能な読み取り/書き込みの分割を検討しましたが、データベースは私のユースケースのボトルネックではありません。最適化する必要があるものを推測するのではなく、xhprof / xhguiのようなプロファイリングを利用することを強くお勧めします。プロファイリングの最初のルールは測定することです。
私はこれについての制作経験はありませんでしたが、掘り下げた後、この記事を見つけました。この記事では、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つのアイデアは、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インスタンスを使用できます。