Искате ли да започнете с най-популярната в света база данни с отворен код и се чудите как трябва да настроите своя MySQL хостинг? Толкова много по подразбиране са Amazon RDS, когато MySQL се представя изключително добре в Azure Cloud. Въпреки че Microsoft Azure предлага управлявано решение, Azure Database, решението има някои основни ограничения, за които трябва да знаете, преди да мигрирате вашите MySQL внедрявания. В тази публикация очертаваме най-добрия начин за хостване на MySQL в Azure, включително управлявани решения, типове екземпляри, репликация с висока наличност, архивиране и типове дискове, които да използвате за оптимизиране на производителността на вашата облачна база данни.
MySQL DBaaS срещу самоуправляван MySQL
Първото нещо, което трябва да вземете предвид, когато претегляте между самоуправление и MySQL Database-as-a-Service (DBaaS) решение е с какви вътрешни ресурси разполагате. Ако четете това, вероятно вече знаете големината на оперативните задачи, свързани с поддържането на производствено внедряване, но за кратко обобщение, има обезпечаване, депровизиране, конфигурации главен-подчинен, архивиране, мащабиране, надстройки, ротации на регистрационни файлове, кръпки на ОС , и мониторинг, за да назовем само няколко.
Вътрешен експерт по MySQL или екип от DBA в зависимост от размера на приложението ви със сигурност може да се справи с тях с вашата организация вместо вас, но въпросът става къде искате усилията на вашия екип да бъдат фокусирани . Мнозина решават да преминат към MySQL DBaaS, за да автоматизират тези отнемащи време задачи, така че да могат да се съсредоточат повече върху разработването и оптимизирането на своите бази данни с приложения. Добър пример би бил бавен анализ на заявки. Въпреки че почти всеки DBaaS предлага инструмент MySQL Slow Query Analyzer, който помага при идентифицирането на заявки за проблеми, тази задача все още изисква човешки умения и интуиция, за да се определи как да се оптимизират тези заявки, влияещи върху производителността на тяхното приложение.
Независимо дали сте стартираща компания или бизнес от Fortune 500, ще откриете, че много организации избират да използват DBaaS, за да оптимизират времето на своя DBA, докато едни и същи типове и размери на бизнеса също така изберете да се придържате към вътрешното самоуправление. За много корпоративни предприятия решението до голяма степен се свежда до персонализиране и контрол. Ето защо ние предупреждаваме да не се използва по подразбиране Azure Database или това е конкурент на AWS, Amazon RDS, тъй като те не ви позволяват да запазите суперпотребителски достъп до MySQL или дори SSH достъп до вашите машини. Освен това, възможността за персонализиране на вашата настройка за внедряване е силно ограничена, като например типове инстанции, RAM, размер на диска или IOPS, които можете да използвате. Ще научите повече за най-добрите типове екземпляри и дискове за използване по-долу и можете да разгледате това сравнение на доставчиците на MySQL, за да видите предимствата и ограниченията на четирите най-добри управлявани решения на MySQL, ScaleGrid, Compose, Azure Database и Amazon RDS.
Внедряване с висока наличност
Ако внедрявате в производство, винаги трябва да настройвате MySQL като главен-подчинен внедряване. Самостоятелните внедрявания са един възел без репликация и наистина трябва да се използват само за среди за разработка или тестване. С разгръщанията главен-подчинен можете да конфигурирате висока наличност, така че ако един от вашите възли се повреди, можете да преминете към подчинен с нулев престой. Това обикновено се настройва или като 3-възел главен-подчинен-подчинен, или 2+1 възел главен-подчинен-кворум. Предимството на използването на кворум е, че това е алтернатива с по-ниска цена, но недостатъкът е, че имате само 2 възела, носещи данни, тъй като другият действа като възел на кворума, за да определи най-добрия курс на отказ. Ако приложението ви може да чете от подчинения, тогава трябва да направите мащабиране при четене, така че те да връщат същите данни от обема на клъстера с минимално забавяне.
Най-добрият начин за хостване на MySQL в Azure Cloud Щракнете за туит
Когато използвате конфигурация главен-подчинен MySQL, препоръчваме да настроите полусинхронна репликация, за да подобрите целостта на данните си с резервиране на данни. Това гарантира, че когато комитът се върне успешно, данните съществуват както в главния, така и в подчинения, така че в случай, че центърът за данни се повреди, вашият MySQL главен може да премине при отказ към подчинен без загуба на данни. Можете да направите това с асинхронна или полусинхронна репликация и да научите повече за това в нашия MySQL High Availability Explained – Part II блог публикация.
И така, как да конфигурираме висока наличност за MySQL в Azure? Трябва да разпределим нашите подчинени екземпляри в различни зони за наличност на Azure (AZ). Така че искаме да сме сигурни, че избираме регион Azure, който има поне 3 AZ, като поставяме всеки екземпляр в различен AZ. Правим това, защото гаранциите за наличност са в рамките на AZ, така че ако 1 зона намалее, вашата база данни с приложения все още може да остане онлайн чрез другите 2 AZ. Зоните за наличност са сравнително нови за Azure, така че ако работите в регион, който не предлага AZ, имате възможност да използвате набори за наличност. Те са малко по-слаби от AZ, но се уверете, че сте разположени в различни домейни и стелажи, за да ви предпазят от потенциално прекъсване. Има и опция за внедряване в различни региони, но това е по-сложна настройка, така че препоръчваме да се свържете, за да обсъдите преди внедряването.
Виртуални мрежи на Azure
Най-добрият начин да защитите вашата база данни от интернет е като я разположите в частна подмрежа, за да сте сигурни, че няма да бъде разкрита. Azure прави това лесно за настройка чрез използването на виртуална мрежа (VNET), която може да бъде конфигурирана за вашите MySQL сървъри. С Azure VNET за MySQL можете да настроите защитени комуникации между вашите сървъри, интернет и дори вашата локална частна облачна мрежа. Те обикновено са конфигурирани да комуникират в една мрежа, но ако трябва да свържете повече от един регион, можете да създадете няколко VNET, за да комуникират чрез виртуална мрежа Peering.
Освен това можете да управлявате своя контрол за достъп до MySQL чрез правилата на мрежовите групи за сигурност (NSG), без да се налага да се справяте с белите списъци за IP. Това не е достъпно чрез Azure Database за MySQL, но както VNET, така и NSG могат да бъдат конфигурирани чрез нашите планове MySQL Bring Your Own Cloud (BYOC) в Azure, където можете да хоствате своите клъстери чрез вашия собствен акаунт в облак.
Типове екземпляри в Azure
Друг важен аспект, който трябва да вземете предвид, е производителността на вашите MySQL екземпляри в публичния облак. Azure cloud предлага множество типове екземпляри, които могат да се използват за вашия MySQL хостинг, включително Es2 v3, Ds2, v2 и Ls4.
Препоръчваме да започнете с оптимизирани за памет типове екземпляри, тъй като базите данни изискват много RAM и търсят възможно най-високата скорост на диска за най-добра производителност. Серията Es2 обикновено е добра отправна точка за повечето приложения MySQL натоварвания. Оттам можете да направите някои тестове на производителността, за да видите дали имате нужда от повече CPU, в който случай, балансирани типове екземпляри или CPU-интензивни типове екземпляри може да обслужват по-добре нуждите ви на MySQL, като например типовете екземпляри Dv3. Вашите тестове за производителност може също да покажат, че имате нужда от повече I/O (вход/изход), можете да преминете към тип инстанция с интензивен диск.
Ако планирате да използвате Azure като ваш доставчик на облак на MySQL за следващите 1-3 години и да поддържате доста последователни конфигурации за внедряване, можете също да помислите за запазени копия. Това по същество са предплатени екземпляри, които ви позволяват да постигнете значителни спестявания на разходите за вашия MySQL хостинг. Средно можете да спестите около 20% до 30% за едногодишни запазени екземпляри и 40% до 50% за 3-годишни запазени екземпляри.
Типове дискове Azure
Първото решение, което трябва да вземете, когато става въпрос за избор на тип диск на Azure за внедряването на MySQL, е дали да използвате управляван срещу неуправляван диск. Неуправляемите дискове са наследените дискове, които Azure предлага, където трябва да настроите акаунта за съхранение, да съпоставите своя диск с акаунта за съхранение и да наблюдавате използването на IOPS и ограниченията за този акаунт за съхранение. Силно препоръчваме да използвате управлявани дискове и ако все още внедрявате с неуправлявани дискове, трябва да помислите за преминаване към управлявани.
MySQL Dev/Test Environment:Стандартни дискове
Има множество управлявани типове дискове, достъпни чрез Azure, като по подразбиране са стандартните дискове. Стандартните дискове могат да поддържат до 500 IOPS (входно/изходни операции в секунда) и са добри за операции по разработване и тестване, тъй като могат да бъдат преоразмерявани динамично, но не трябва да се използват за внедряване на MySQL.
Производствени внедрявания на MySQL:Premium дискове
За вашите MySQL производствени сървъри силно препоръчваме да използвате премиум дискове на Azure. Има голямо разнообразие от първокласни дискове, от които можете да избирате. За всеки първокласен диск можете да изберете най-добрия размер и всеки размер идва с различни осигурени IOPS, така че можете да изберете този, който най-добре отговаря на нуждите на вашето приложение.
Производствено внедряване на MySQL:локален SSD
Azure Local SSD са високопроизводителна алтернатива на първокласните дискове, обикновено най-подходящи за големи клъстери. Локалните SSD осигуряват много по-висока I/O производителност и най-добрата пропускателна способност в Azure. Но те имат недостатък в това, че са ефимерни дискове, а не постоянно хранилище, така че ако спрете екземпляра, данните изчезват. Препоръчваме серията Ls v2, която е много бърза, но внимавайте, че процесорът е наистина слаб, което може да причини тесни места в машината.
Архивиране на MySQL в Azure
Най-добрият начин за архивиране на вашите MySQL данни в Azure е чрез използване на моментни снимки на управляван диск. Моментната снимка е версия на диска само за четене във времето. Тези резервни копия могат да се четат, копират или изтриват, но имайте предвид, че не могат да бъдат променяни. Добра идея е да направите пълно архивиране, така че всичките ви бази данни, потребители и настройки да бъдат архивирани в екземпляра, в случай че някога се наложи да възстановите база данни на MySQL. Също така е добра идея да шифровате вашите резервни моментни снимки, така че архивът да може да бъде възстановен само на машината, на която е направено резервното копие.
Вашите резервни копия на MySQL ще доведат до допълнителни такси за съхранение на данни в Azure, освен ако не използвате всеобхватно решение за MySQL на Azure като нашите планове за Специализиран хостинг в ScaleGrid. За да контролирате разходите, е добра идея да автоматизирате архивирането си чрез персонализиран график, който ви позволява да конфигурирате честотата на вашите архивни копия, максималния брой резервни копия за запазване и целта си за архивиране. Това, разбира се, също така ви помага да гарантирате, че вашите MySQL данни се архивират редовно в случай на загуба на данни във вашето производствено внедряване, така че да можете бързо да се възстановите със скорошно архивиране.
Ако имате въпроси относно най-добрия начин за хостване на MySQL в Azure, оставете ни коментар по-долу или се свържете с нас на support@scalegrid. io Можете също да започнете безплатна 30-дневна пробна версия, за да проучите предимствата на използването на напълно управлявана услуга MySQL за подобряване на производителността на внедряванията си.
