जवाबों:
हमें MySQL समूहों का एक बहुत बड़ा अनुभव मिला है - और पेर्कोना ने कई अवसरों पर हमारे साथ काम किया है जब जटिल कॉन्फ़िगरेशन की सीमाओं को धक्का दे रहा है।
Magento है बंटवारे बंद पढ़ता के देशी रूप सक्षम / लिखते विभिन्न डेटाबेस सर्वर से (कुछ टूट विज्ञप्ति के अपवाद के, जैसे ई 1.11 के साथ।) - आप की भरपाई करने के लिए अनुमति देता है selectएक अतिरिक्त (या अधिक) सर्वर (ओं) को लोड; और update/writeएक ही मास्टर के लिए सभी प्रश्नों को अग्रेषित करना।
यह एक अधिक उपयुक्त प्रश्न है। MageStack जैसे समर्पित Magento ऑपरेटिंग सिस्टम के साथ - यह इन-बिल्ट सर्वर साइड एडवांस कैशिंग तकनीकों के लिए उपलब्ध होने और आसानी से उपयोग किए जाने के लिए अधिक सामान्य होता जा रहा है (जैसे वार्निश फ्रंट एंड कैशिंग और रेडिस बैक एंड कैशिंग)।
ऐतिहासिक रूप से, Magento के MySQL द्वारा कभी भी बाध्य नहीं किया गया है - बल्कि PHP। लेकिन जैसा कि वार्निश और पूर्ण पृष्ठ कैशिंग (FPC) का अधिक बार उपयोग किया जाता है, बार-बार किए जाने वाले कार्यों (श्रेणी / उत्पाद भार, लगातार खोजों) का बोझ अचानक अवशोषित हो जाता है और PHP एक बोझ से कम हो जाता है। वास्तव में, यह केवल सामग्री को शुरू में उत्पन्न करने के लिए वास्तव में आता है, या गैर-कैशेबल परिदृश्यों को पूरा करता है (कार्ट में जोड़ें, ऑर्डर पूरा होने आदि); स्पष्टीकरण के उद्देश्य के लिए हम जानबूझकर प्रशासनिक भार की अनदेखी कर रहे हैं ।
हम हमेशा इस तथ्य से खड़े हुए हैं कि MySQL अधिकांश खुदरा विक्रेताओं के लिए चिंता का विषय नहीं है, जैसा कि यहां और यहां दोनों में देखा गया है । लेकिन अगर आपका प्रति घंटे सैकड़ों ऑर्डर प्रसंस्करण के क्षेत्र में है, तो एकल या दोहरे अंक नहीं हैं - यह जल्द ही अनुकूलन के लिए एक क्षेत्र बन जाएगा।
अंततः छोटे स्टोर के लिए (<25k दैनिक अद्वितीय आगंतुक)
आपके प्रयासों को केवल एक उपयुक्त होस्ट ढूंढने पर बेहतर ध्यान केंद्रित किया जाएगा जो ऑफसेट से होने के लिए सही हार्डवेयर का सुझाव दे सकता है और जिसने आपके स्टोर के लिए सबसे इष्टतम फैशन में मशीन को कॉन्फ़िगर किया है । अपना समय बर्बाद न करें मास्टर / स्लेव या मास्टर / मास्टर कॉन्फ़िगरेशन का पीछा करें - जिससे कोई प्रदर्शन लाभ नहीं होगा और अंततः लगातार ध्यान और उन्नत MySQL ज्ञान की आवश्यकता होगी।
अंततः हार्डवेयर साइज़िंग और चयन में MySQL अनुकूलन की तुलना में खेलने के लिए एक बड़ा हिस्सा होगा।
लेकिन बड़े स्टोर्स के लिए
जैसे-जैसे आपकी दुकान बढ़ने लगती है, कॉम्प्लेक्स या ट्रांजेक्शनल लोड अधिक जटिल insertsऔर बार-बार काम पूरा करने के बोझ से अधिक हो जाता है updates। प्रत्येक नए आदेश के अलावा कैटलॉग स्टॉक की गिरावट, भुगतान गेटवे से कॉलबैक और ईपीओएस / ईआरपी सिस्टम से अपडेट को ट्रिगर किया जाएगा। संबंधित उत्पादों / श्रेणियों के संबंधित कैश पर्ज के साथ इसे मिलाएं और आप जल्द ही MySQL लोड को असमान रूप से बढ़ाते हुए देखेंगे।
मल्टी-मास्टर कभी भी एक समाधान नहीं है जिसे हम व्यवहार्य विकल्प के रूप में सुझाते हैं या विचार करते हैं, लेकिन मास्टर / स्लेव माध्यमिक / तृतीयक नोड्स के लिए रीड लोड को ऑफसेट करके लाभ (हम तनाव, एंटरप्राइज-साइज़ स्टोर्स पर) प्राप्त कर सकते हैं।
पहले अपने दासों को कॉन्फ़िगर करें। हम पेरकोना उपयोगिताओं और 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>सूत्रों का कहना है
सामान्य मैगनेटो में सीपीयू बाउंड होता है, न कि डेटाबेस बाउंड, और अधिकांश सीपीयू गतिविधि को कैश किया जा सकता है, यही वजह है कि आपको वार्निश / नग्नेक्स सेटअप पर बहुत सारे ट्यूटोरियल मिलेंगे। आप अपने व्यवस्थापक को यहां विस्तृत के रूप में एक अलग वेबनोड पर ले जा सकते हैं ।
सामान्य मजबूती के लिए, हिरन के लिए सबसे अच्छा बैंग एक प्रबंधित MySQL सेवा होगी।
मेरे पास केवल अमेज़ॅन आरडीएस के साथ अनुभव है, लेकिन वे असफलता, बैकअप, अपग्रेड, स्केलिंग अप / डाउन को स्वचालित करते हैं, साथ ही प्रतिकृति निर्माण भी पढ़ते हैं। तो आपके पास एक उच्च उपलब्धता मास्टर नोड हो सकता है जिसमें स्वचालित विफलता है - अमेज़ॅन एक अनुकूलित बाइनरी लॉग प्रतिकृति का उपयोग करता है ताकि दास को सिंक में रखा जा सके, विफलता को आमतौर पर 2 मिनट से कम समय लगता है, और फिर आप जितने पढ़ सकते हैं उतने ही प्रतिकृति बना सकते हैं अपनी रिपोर्टिंग / एकीकरण आवश्यकताओं के लिए पैमाना बनाने की आवश्यकता है।
मैंने स्प्लिटिंग रीड्स / राइट्स में देखा, जो मैगेंटो की वास्तुकला के साथ बहुत ही उल्लेखनीय है, लेकिन डेटाबेस मेरे उपयोग के मामले में एक अड़चन नहीं है। मैं अत्यधिक अनुकूलित करने की आवश्यकता पर अनुमान लगाने के बजाय xhprof / xhgui जैसे प्रोफाइलिंग का उपयोग करने की सलाह देता हूं । प्रोफाइलिंग का पहला नियम माप करना है।
मुझे इसके साथ कोई उत्पादन अनुभव नहीं था, लेकिन कुछ खुदाई के बाद मुझे यह लेख मिला है । इस लेख में कोई बताता है कि मैगेंटो के लिए मास्टर-स्लेव प्रतिकृति को कैसे सेटअप किया जाए, इसलिए यह आपके लिए उपयोगी हो सकता है।
सबसे महत्वपूर्ण बिट:
/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 सर्वर को पुनरारंभ करें
एक विचार यह है कि आप dns राउंड-रॉबिन का उपयोग करके अपने कैटलॉग रीड्स को स्लेव सर्वर (एस) में विभाजित कर सकते हैं ।
इस प्रकार सेटअप सामान्य मास्टर -> MySQL में दास (एस) प्रतिकृति।
तब अपने Magento सेटअप में आप अपने कैटलॉग को अपने राउंड-रॉबिन कॉन्फ़िगर किए गए डीएनएस होस्ट से रीड करने के लिए कॉन्फ़िगर कर सकते हैं। राइट्स आपके मास्टर डेटाबेस में रहेंगे।
आप इसमें कर सकते हैं 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 उदाहरण का उपयोग करने के लिए किसी भी कोर (और 3 पार्टी) मॉड्यूल को पुनर्निर्देशित कर सकते हैं।