วิธีเพิ่มประสิทธิภาพสถาปัตยกรรมฐานข้อมูลสำหรับไซต์ที่มีปริมาณมาก

คำถามเกี่ยวกับรายการการกำหนดค่า Mysql ที่เฉพาะเจาะจงน้อยลง แต่เพิ่มเติมเกี่ยวกับการจัดการหลายฐานข้อมูลแยกการอ่านและเขียนไปยังเซิร์ฟเวอร์ฐานข้อมูลหลายรายการ, มาสเตอร์ + มาสเตอร์? Master + Slaves หลายตัว?

ผู้คนมีประสบการณ์ที่ดีที่สุดและมีตัวอย่างใดบ้างเกี่ยวกับวิธีการบรรลุเป้าหมายนี้

เรามีประสบการณ์มากมายในกลุ่ม MySQL และ Percona ได้ทำงานร่วมกับเราหลายครั้งเมื่อผลักขอบเขตของการกำหนดค่าที่ซับซ้อน

วีโอไอพีสามารถจัดการกับทาสแบบอ่านอย่างเดียว

วีโอไอพีคือกำเนิดความสามารถในการแยกออกอ่าน / เขียนไปยังเซิร์ฟเวอร์ของฐานข้อมูลที่แตกต่างกัน (ยกเว้นรุ่นเสียไม่กี่เช่น EE 1.11.) - ช่วยให้คุณเพื่อชดเชยselectภาระที่จะเพิ่ม (หรือมากกว่า) เซิร์ฟเวอร์ (s); และส่งต่อupdate/writeแบบสอบถามทั้งหมดไปยังต้นแบบเดียว

เมื่อไหร่ที่ฉันควรทำ

นี่เป็นคำถามที่เหมาะสมกว่า ด้วยระบบปฏิบัติการ Magento โดยเฉพาะเช่นMageStackมันเป็นเรื่องธรรมดามากขึ้นสำหรับเทคนิคการแคชขั้นสูงในฝั่งเซิร์ฟเวอร์ที่จะใช้งานและใช้งานได้ง่าย (เช่น Varnish front end caching และ Redis back end caching)

ประวัติศาสตร์วีโอไอพีไม่เคยถูกผูกมัดโดย MySQL - แต่แทนที่จะเป็น PHP แต่เนื่องจากมีการใช้น้ำยาเคลือบเงาและเต็มหน้า (FPC) บ่อยครั้งภาระของงานซ้ำ ๆ (หมวดหมู่ / โหลดผลิตภัณฑ์การค้นหาบ่อย) จะถูกดูดซับอย่างฉับพลันและ PHP ก็กลายเป็นภาระน้อยกว่า อันที่จริงมีเพียงการเล่นเพื่อสร้างเนื้อหาในตอนแรกหรือสถานการณ์ที่ไม่สามารถเข้าถึงได้ทั้งหมด (เพิ่มในรถเข็นการสั่งซื้อเสร็จสิ้นเป็นต้น) สำหรับวัตถุประสงค์ของการคำอธิบายที่เรากำลังจงใจละเลยภาระการบริหาร

เราได้ยืนอยู่เสมอโดยความจริงที่ว่า MySQL ไม่ได้เป็นพื้นที่ของความกังวลสำหรับร้านค้าปลีกมากที่สุดเท่าที่เห็นทั้งที่นี่และที่นี่ แต่ถ้าหากคุณอยู่ในพื้นที่ของการประมวลผลคำสั่งหลายร้อยต่อชั่วโมงไม่ใช่หลักเดียวหรือสองหลัก - เร็ว ๆ นี้จะกลายเป็นพื้นที่สำหรับการเพิ่มประสิทธิภาพ

ที่สุดสำหรับร้านค้าขนาดเล็ก (<25k ผู้เข้าชมที่ไม่ซ้ำทุกวัน)

ความพยายามของคุณจะดีกว่าไกลที่มุ่งเน้นเพียงแค่การหาพื้นที่ที่เหมาะสมที่สามารถแนะนำฮาร์ดแวร์ที่เหมาะสมที่จะไปจากที่ชดเชยและที่ได้รับการกำหนดค่าเครื่องในแบบที่เหมาะสมที่สุดสำหรับการจัดเก็บของคุณ อย่าเสียเวลาในการติดตามการกำหนดค่า Master / Slave หรือ Master / Master - ซึ่งจะไม่มีผลประโยชน์ด้านประสิทธิภาพและในที่สุดจะต้องได้รับความสนใจอย่างต่อเนื่องและความรู้ MySQL ขั้นสูง

การปรับขนาดและการเลือกฮาร์ดแวร์ในท้ายที่สุดจะมีส่วนสำคัญในการเล่นมากกว่าการเพิ่มประสิทธิภาพ MySQL

แต่สำหรับร้านค้าขนาดใหญ่

ในฐานะที่เป็นร้านค้าของคุณเริ่มที่จะเติบโตแปลงหรือโหลดการทำธุรกรรมจะกลายเป็นภาระมากขึ้นกับงานที่ทำซ้ำของการจบที่ซับซ้อนและinserts updatesการเพิ่มคำสั่งซื้อใหม่แต่ละรายการจะทริกเกอร์การลดสต็อคแคตตาล็อกการเรียกคืนจากเกตเวย์การชำระเงินและการอัปเดตจากระบบ EPOS / ERP รวมสิ่งนี้กับการล้างแคชที่เกี่ยวข้องของผลิตภัณฑ์ / หมวดหมู่ที่เกี่ยวข้องและในไม่ช้าคุณจะเห็นการโหลด MySQL เพิ่มขึ้นอย่างไม่เป็นสัดส่วน

Multi-master ไม่ใช่วิธีการแก้ปัญหาที่เราแนะนำหรือพิจารณาว่าเป็นตัวเลือกที่ทำงานได้ แต่ Master / Slave สามารถให้ประโยชน์ได้ (เราเน้นที่ร้านค้าขนาดใหญ่ขององค์กร) โดยการชดเชยการอ่านไปยังโหนดสำรอง / ตติยภูมิ

แต่ฉันก็ยังอยากจะทำ

ก่อนกำหนดค่าทาสของคุณ เราเป็นผู้สนับสนุนรายใหญ่ของสาธารณูปโภค Percona และสาขา MySQL - พวกเขามีเครื่องมือที่เหมาะสำหรับการสำรองข้อมูลที่ร้อนแรงของฐานข้อมูลที่มีอยู่ของคุณ - 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>

แหล่งที่มา

โดยทั่วไปแล้ววีโอไอพีจะมีข้อ จำกัด ของ CPU ไม่ใช่ฐานข้อมูลและกิจกรรมของ CPU ส่วนใหญ่สามารถถูกแคชได้ซึ่งเป็นสาเหตุที่คุณจะพบบทเรียนมากมายในการตั้งค่าวานิช / nginx นอกจากนี้คุณยังสามารถย้ายผู้ดูแลระบบของคุณไปยัง Webnode แยกตามรายละเอียดที่นี่

เพื่อความทนทานโดยทั่วไปปังที่ดีที่สุดสำหรับเจ้าชู้จะเป็นบริการ MySQL ที่มีการจัดการ

ฉันมีประสบการณ์กับ Amazon RDS เท่านั้น แต่พวกมันทำการ failover สำรองข้อมูลอัพเกรดปรับขนาดขึ้น / ลงรวมถึงอ่านการสร้างแบบจำลองโดยอัตโนมัติ ดังนั้นคุณสามารถมีโหนดหลักที่มีความพร้อมใช้งานสูงที่มีการเฟลโอเวอร์อัตโนมัติ - Amazon ใช้การจำลองแบบบันทึกแบบไบนารีที่กำหนดเองเพื่อให้สลาฟซิงค์ตรงกันโดยปกติการเฟลโอเวอร์จะใช้เวลาน้อยกว่า 2 นาทีและจากนั้นคุณสามารถสร้าง จำเป็นต้องขยายความต้องการการรายงาน / การรวมระบบของคุณ

ฉันดูแยกอ่าน / เขียนซึ่งทำได้ดีมากกับสถาปัตยกรรมของ Magento แต่ฐานข้อมูลไม่ใช่คอขวดในกรณีที่ใช้งานของฉัน ฉันขอแนะนำให้ใช้การทำโปรไฟล์เช่น xhprof / xhguiแทนที่จะคาดเดาสิ่งที่จำเป็นต้องปรับให้เหมาะสม กฎข้อแรกของการทำโปรไฟล์คือการวัด

ฉันไม่ได้มีประสบการณ์การผลิตใด ๆ กับเรื่องนี้ แต่หลังจากขุดบางอย่างที่ฉันได้พบนี้บทความ ในบทความนี้มีคนอธิบายถึงวิธีการตั้งค่าการจำลองแบบ master-slave สำหรับ 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 ทั้งสองหลังจากนั้น

หนึ่งความคิดคือการที่คุณสามารถแยกแคตตาล็อกของคุณอ่านไปยังเซิร์ฟเวอร์ทาส (s) ใช้ DNS robin ปัด

ดังนั้นการตั้งค่า master ปกติ -> การจำลองแบบทาส (s) ใน MySQL

จากนั้นในการตั้งค่า Magento ของคุณคุณสามารถกำหนดค่าแคตตาล็อกของคุณให้อ่านจากโฮสต์ DNS ที่กำหนดค่าแบบรอบตัวของคุณ การเขียนจะยังคงอยู่ในฐานข้อมูลหลักของคุณ

คุณสามารถทำได้ 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 ที่แตกต่างกันในลักษณะเดียวกัน