{"id":82113,"date":"2020-05-19T13:42:51","date_gmt":"2020-05-19T11:42:51","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/orchestrator-i-vip-kak-ha-reshenie-dlya-klastera-mysql"},"modified":"2020-05-19T13:42:51","modified_gmt":"2020-05-19T11:42:51","slug":"orchestrator-i-vip-kak-ha-reshenie-dlya-klastera-mysql","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/orchestrator-i-vip-kak-ha-reshenie-dlya-klastera-mysql","title":{"rendered":"Orchestrador e VIP como solu\u00e7\u00e3o de HA para o cluster MySQL","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Na Sitimobil, usamos o banco de dados MySQL como nosso principal reposit\u00f3rio de dados persistentes. Temos v\u00e1rios clusters de banco de dados para diferentes servi\u00e7os e finalidades.<\/p>\n<p>A disponibilidade cont\u00ednua do mestre \u00e9 um indicador cr\u00edtico de desempenho de todo o sistema e suas partes individuais. A recupera\u00e7\u00e3o autom\u00e1tica do cluster em caso de falha do mestre reduz significativamente o tempo de resposta a incidentes e o tempo de inatividade do sistema. Neste artigo, abordarei o esquema de alta disponibilidade (HA) do cluster MySQL com base em <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/github\/orchestrator\">MySQL Orchestrator<\/a><\/noindex> e endere\u00e7os IP virtuais (VIP).<\/p>\n<p><img decoding=\"async\" alt=\"Orchestrador e VIP como solu\u00e7\u00e3o de HA para o cluster MySQL\" src=\"\/wp-content\/uploads\/2020\/05\/a76ef93caee0fc13d2afb12c25a25531.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h1>Solu\u00e7\u00e3o de HA baseada em VIP<\/h1>\n<p>\nPrimeiro, falarei brevemente sobre o que \u00e9 o nosso sistema de armazenamento de dados.<\/p>\n<p>Usamos um esquema cl\u00e1ssico de replica\u00e7\u00e3o com um \u00fanico mestre dispon\u00edvel para grava\u00e7\u00e3o e v\u00e1rias r\u00e9plicas que s\u00e3o usadas apenas para leitura. O cluster pode conter um mestre intermedi\u00e1rio \u2014 um n\u00f3 que \u00e9 simultaneamente uma r\u00e9plica e um mestre para outros. Os clientes acessam as r\u00e9plicas atrav\u00e9s do HAProxy, o que permite distribuir a carga uniformemente e escalar facilmente. O uso do HAProxy \u00e9 devido a raz\u00f5es hist\u00f3ricas, e agora estamos em processo de migra\u00e7\u00e3o para ProxySQL.<\/p>\n<p>A replica\u00e7\u00e3o \u00e9 realizada em modo semiss\u00edncrono com base em <code>GTID<\/code>. Isso significa que pelo menos uma r\u00e9plica deve gravar a transa\u00e7\u00e3o no log antes que ela seja considerada bem-sucedida. Esse modo de replica\u00e7\u00e3o garante um equil\u00edbrio otimizado entre desempenho e integridade dos dados em caso de falha do n\u00f3 principal. Na maioria das vezes, todas as altera\u00e7\u00f5es s\u00e3o transmitidas do mestre para as r\u00e9plicas por meio de <code>Row Based Replication (RBR)<\/code>, mas alguns n\u00f3s podem ter <code>mixed binlog format<\/code>.<\/p>\n<p>O Orchestrador atualiza periodicamente o estado da topologia do cluster, analisa as informa\u00e7\u00f5es recebidas e, em caso de problemas, pode iniciar o processo de recupera\u00e7\u00e3o autom\u00e1tica. O pr\u00f3prio processo \u00e9 responsabilidade do desenvolvedor, uma vez que pode ser implementado de v\u00e1rias maneiras: com base em VIP, DNS, utilizando servi\u00e7os de descoberta (service discovery) ou mecanismos feitos sob medida. <\/p>\n<p>Uma das maneiras simples de recuperar o mestre em caso de falha \u00e9 utilizar endere\u00e7os VIP flutuantes.<\/p>\n<p>O que voc\u00ea precisa saber sobre esta solu\u00e7\u00e3o antes de prosseguir:<\/p>\n<ul>\n<li>VIP \u00e9 um endere\u00e7o IP que n\u00e3o est\u00e1 vinculado a uma interface de rede f\u00edsica espec\u00edfica. Quando um n\u00f3 falha ou durante manuten\u00e7\u00f5es programadas, podemos transferir o VIP para outro recurso com tempo de inatividade m\u00ednimo.\n<\/li>\n<li>Liberar e fornecer um endere\u00e7o IP virtual s\u00e3o opera\u00e7\u00f5es baratas e r\u00e1pidas.\n<\/li>\n<li>Para trabalhar com VIP, \u00e9 necess\u00e1rio ter acesso ao servidor via SSH ou usar utilit\u00e1rios especiais, como <code>keepalived<\/code>.\n<\/li>\n<\/ul>\n<p>\nVamos considerar os poss\u00edveis problemas com nosso mestre e mostrar como o mecanismo de recupera\u00e7\u00e3o autom\u00e1tica deve funcionar.<\/p>\n<h4>A conectividade de rede com o mestre est\u00e1 perdida, ou houve um problema no n\u00edvel de hardware e o servidor est\u00e1 indispon\u00edvel.<\/h4>\n<p><\/p>\n<ol>\n<li>O orquestrador atualiza a topologia do cluster, cada r\u00e9plica informa sobre a indisponibilidade do mestre. O orquestrador inicia o processo de elei\u00e7\u00e3o de uma r\u00e9plica adequada para assumir o papel de novo mestre e come\u00e7a a recupera\u00e7\u00e3o.\n<\/li>\n<li>Tentamos remover o VIP do antigo mestre \u2014 sem sucesso.\n<\/li>\n<li>A r\u00e9plica muda para o papel de mestre. A topologia \u00e9 reconstru\u00edda.\n<\/li>\n<li>Adicionamos uma nova interface de rede com VIP. Como n\u00e3o foi poss\u00edvel remover o VIP, em segundo plano iniciamos o envio peri\u00f3dico de solicita\u00e7\u00f5es <b>gratuitous ARP<\/b>. Este tipo de solicita\u00e7\u00e3o\/resposta permite atualizar a tabela de correspond\u00eancia de endere\u00e7os IP e MAC nos switches conectados, notificando assim sobre a mudan\u00e7a do nosso VIP. Isso minimiza a probabilidade de <code>split brain<\/code> ao reverter para o antigo mestre. \n<\/li>\n<li>Todas as novas conex\u00f5es s\u00e3o imediatamente redirecionadas para o novo mestre. Conex\u00f5es antigas falham, e s\u00e3o feitas novas tentativas ao banco de dados no n\u00edvel do aplicativo.\n<\/li>\n<\/ol>\n<p><\/p>\n<h4>O servidor est\u00e1 funcionando normalmente, houve uma falha no n\u00edvel do SGBD.<\/h4>\n<p>\nO algoritmo \u00e9 semelhante ao caso anterior: atualiza\u00e7\u00e3o da topologia e in\u00edcio do processo de recupera\u00e7\u00e3o. Como o servidor est\u00e1 acess\u00edvel, liberamos com sucesso o VIP do antigo mestre, transferimos para o novo e enviamos v\u00e1rias solicita\u00e7\u00f5es ARP. Um poss\u00edvel retorno do antigo mestre n\u00e3o deve afetar o cluster reestruturado e o funcionamento do aplicativo.<\/p>\n<h4>Outros problemas<\/h4>\n<p>\nFalha de r\u00e9plicas ou mestres intermedi\u00e1rios <em>n\u00e3o leva<\/em> a a\u00e7\u00f5es autom\u00e1ticas e requer interven\u00e7\u00e3o manual.<\/p>\n<p>A interface de rede virtual \u00e9 sempre adicionada temporariamente, ou seja, ap\u00f3s a reinicializa\u00e7\u00e3o do servidor, o VIP n\u00e3o \u00e9 atribu\u00eddo automaticamente. Cada inst\u00e2ncia do banco de dados inicia por padr\u00e3o no modo somente leitura, e o orquestrador muda automaticamente o novo mestre para grava\u00e7\u00e3o e tenta estabelecer <code>somente leitura<\/code> no antigo mestre. Essas a\u00e7\u00f5es visam reduzir a probabilidade <code>split brain<\/code>.<\/p>\n<p>Durante o processo de recupera\u00e7\u00e3o, podem surgir problemas que tamb\u00e9m devem ser notificados atrav\u00e9s da interface do usu\u00e1rio do orquestrador, al\u00e9m dos m\u00e9todos de monitoramento padr\u00e3o. Expandimos a REST API, adicionando essa possibilidade (<noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/openark\/orchestrator\/pull\/1088\">PR<\/a><\/noindex> est\u00e1 atualmente em revis\u00e3o).<\/p>\n<p>O esquema geral da solu\u00e7\u00e3o HA \u00e9 apresentado abaixo.<\/p>\n<p><img decoding=\"async\" alt=\"Orchestrador e VIP como solu\u00e7\u00e3o de HA para o cluster MySQL\" src=\"\/wp-content\/uploads\/2020\/05\/485dbbc8f2b1a7595f5fa4f36ad92f7e.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h1>Escolhendo um novo mestre<\/h1>\n<p>\nO orquestrador \u00e9 suficientemente inteligente e tenta escolher <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/openark\/orchestrator\/blob\/5126b849ae4f655e1cbe0fbddfa0d7299674f712\/go\/inst\/instance_utils.go#L112\">a r\u00e9plica mais adequada<\/a><\/noindex> como o novo mestre com base nos seguintes crit\u00e9rios:<\/p>\n<ul>\n<li>atraso da r\u00e9plica em rela\u00e7\u00e3o ao mestre;\n<\/li>\n<li>vers\u00e3o do MySQL do mestre e da r\u00e9plica;\n<\/li>\n<li>tipo de replica\u00e7\u00e3o (RBR, SBR ou mixed);\n<\/li>\n<li>localiza\u00e7\u00e3o em um ou diferentes data centers;\n<\/li>\n<li>a exist\u00eancia <code>GTID problem\u00e1tico<\/code> \u2014 transa\u00e7\u00f5es que foram executadas na r\u00e9plica e est\u00e3o ausentes no mestre;\n<\/li>\n<li>tamb\u00e9m s\u00e3o considerados regras de sele\u00e7\u00e3o do usu\u00e1rio.\n<\/li>\n<\/ul>\n<p>\nNem toda r\u00e9plica \u00e9 um candidato ideal para o papel de mestre. Por exemplo, a r\u00e9plica pode ser usada para backup de dados ou o servidor pode ter uma configura\u00e7\u00e3o de hardware mais fraca. O orquestrador <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/openark\/orchestrator\/blob\/master\/docs\/topology-recovery.md#adding-promotion-rules\">suporta<\/a><\/noindex> regras manuais, atrav\u00e9s das quais voc\u00ea pode personalizar suas prefer\u00eancias para a escolha do candidato, desde os mais preferenciais at\u00e9 os ignorados.<\/p>\n<h1>Tempo de resposta e recupera\u00e7\u00e3o<\/h1>\n<p>\nNo caso de um incidente, \u00e9 importante minimizar o tempo de inatividade do sistema, portanto, vamos considerar os par\u00e2metros do MySQL que afetam a constru\u00e7\u00e3o e atualiza\u00e7\u00e3o da topologia do cluster pelo orquestrador:<\/p>\n<ul>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/dev.mysql.com\/doc\/refman\/5.7\/en\/replication-options-slave.html#sysvar_slave_net_timeout\"><code>slave_net_timeout<\/code><\/a><\/noindex> \u2014 n\u00famero de segundos que a r\u00e9plica espera pela chegada de novos dados ou um sinal heartbeat do mestre, antes que a conex\u00e3o seja considerada perdida e uma reconex\u00e3o seja realizada. Quanto menor o valor, mais r\u00e1pido a r\u00e9plica poder\u00e1 determinar que a conex\u00e3o com o mestre foi interrompida. Definimos esse valor como 5 segundos.\n<\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/dev.mysql.com\/doc\/refman\/5.7\/en\/change-master-to.html\"><code>MASTER_CONNECT_RETRY<\/code><\/a><\/noindex> \u2014 o n\u00famero de segundos entre as tentativas de reconex\u00e3o. Em caso de problemas de rede, um valor baixo para esse par\u00e2metro permitir\u00e1 uma r\u00e1pida reconex\u00e3o e evitar\u00e1 o in\u00edcio do processo de recupera\u00e7\u00e3o do cluster. O valor recomendado \u00e9 de 1 segundo.\n<\/li>\n<li><code>MASTER_RETRY_COUNT<\/code> \u2014 o n\u00famero m\u00e1ximo de tentativas de reconex\u00e3o. \n<\/li>\n<li><code>MASTER_HEARTBEAT_PERIOD<\/code> \u2014 o intervalo em segundos ap\u00f3s o qual o mestre envia um sinal de heartbeat. Por padr\u00e3o, \u00e9 igual \u00e0 metade do valor <code>slave_net_timeout<\/code>.\n<\/li>\n<\/ul>\n<p>\nPar\u00e2metros do orquestrador:<\/p>\n<ul>\n<li><code>DelayMasterPromotionIfSQLThreadNotUpToDate<\/code> \u2014 se igual a <code>verdadeiro<\/code>, o papel de mestre n\u00e3o ser\u00e1 aplicado ao replicador candidato at\u00e9 que o fluxo SQL do replicador tenha processado todas as transa\u00e7\u00f5es n\u00e3o aplicadas do Relay Log. Usamos essa op\u00e7\u00e3o para evitar a perda de transa\u00e7\u00f5es em condi\u00e7\u00f5es de atrasos de todos os replicadores candidatos.\n<\/li>\n<li><code>InstancePollSeconds<\/code> \u2014 a frequ\u00eancia de constru\u00e7\u00e3o e atualiza\u00e7\u00e3o da topologia.\n<\/li>\n<li><code>RecoveryPollSeconds<\/code> \u2014 a frequ\u00eancia de an\u00e1lise da topologia. Ao detectar um problema, a recupera\u00e7\u00e3o da topologia \u00e9 iniciada. Essa<noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/github\/orchestrator\/blob\/548265494b3107ca2581d6ccee059e062a759b77\/go\/config\/config.go#L45\"> constante<\/a><\/noindex>, igual a 1 segundo.\n<\/li>\n<\/ul>\n<p>\nCada n\u00f3 do cluster \u00e9 consultado pelo orquestrador uma vez a cada <code>InstancePollSeconds<\/code> segundos. Ao detectar um problema, o estado do cluster \u00e9 for\u00e7osamente<noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/github\/orchestrator\/blob\/548265494b3107ca2581d6ccee059e062a759b77\/go\/logic\/topology_recovery.go#L1409\"> atualizado<\/a><\/noindex>, e ent\u00e3o uma decis\u00e3o final \u00e9 tomada sobre a execu\u00e7\u00e3o da recupera\u00e7\u00e3o. Ao experimentar v\u00e1rios par\u00e2metros de DB e do orquestrador, conseguimos reduzir o tempo de resposta e recupera\u00e7\u00e3o para 30 segundos.<\/p>\n<h1>Bancada de Testes<\/h1>\n<p>\nCome\u00e7amos o teste do esquema de HA com o desenvolvimento de uma <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/ParshinPavel\/mysql-ha-sandbox\">banda de teste local<\/a><\/noindex> e posterior implementa\u00e7\u00e3o em ambientes de teste e produ\u00e7\u00e3o. A banda local \u00e9 totalmente automatizada com base em Docker e permite experimentar com a configura\u00e7\u00e3o do orquestrador e da rede, escalar o cluster de 2-3 servidores para v\u00e1rias dezenas e realizar simula\u00e7\u00f5es em um ambiente seguro. <\/p>\n<p>Durante os exerc\u00edcios, escolhemos um dos m\u00e9todos de simula\u00e7\u00e3o de problemas: eliminar rapidamente o mestre usando <code>kill -9<\/code>, encerrar o processo suavemente e parar o servidor (<code>docker-compose stop<\/code>), simular problemas de rede usando <code>iptables -j REJECT<\/code> ou <code>iptables -j DROP<\/code>. Esperamos os seguintes resultados:<\/p>\n<ul>\n<li>o orquestrador detectar\u00e1 problemas com o mestre e atualizar\u00e1 a topologia em no m\u00e1ximo 10 segundos;\n<\/li>\n<li>o processo de recupera\u00e7\u00e3o ser\u00e1 iniciado automaticamente: a configura\u00e7\u00e3o de rede ser\u00e1 alterada, o papel de mestre ser\u00e1 transferido para o replicador, e a topologia ser\u00e1 reconstru\u00edda;\n<\/li>\n<li>o novo mestre estar\u00e1 dispon\u00edvel para grava\u00e7\u00e3o, as r\u00e9plicas ao vivo n\u00e3o ser\u00e3o perdidas durante o processo de reconstru\u00e7\u00e3o;\n<\/li>\n<li>os dados come\u00e7ar\u00e3o a ser gravados no novo mestre e replicados;\n<\/li>\n<li>o tempo total de recupera\u00e7\u00e3o n\u00e3o exceder\u00e1 30 segundos.\n<\/li>\n<\/ul>\n<p>\nComo voc\u00ea sabe, o sistema pode se comportar de maneira diferente em ambientes de teste e produ\u00e7\u00e3o devido \u00e0 configura\u00e7\u00e3o diferente do hardware e da rede, diferen\u00e7as na carga sint\u00e9tica e real, etc. Por isso, periodicamente realizamos exerc\u00edcios em condi\u00e7\u00f5es reais, verificando como o sistema se comporta em caso de perda de conectividade de rede ou degrada\u00e7\u00e3o de suas partes. No futuro, queremos construir uma infraestrutura completamente id\u00eantica para ambos os ambientes e automatizar seus testes.<\/p>\n<h1>Como resultado, obtemos um servi\u00e7o de \"monitoramento como servi\u00e7o\", automatizado na linha de produ\u00e7\u00e3o de integra\u00e7\u00e3o cont\u00ednua. O desenvolvedor ou testador precisa apenas definir a lista de m\u00e9tricas em um arquivo JSON, e tudo o mais acontece automaticamente. Obtemos um controle de qualidade transparente dos lan\u00e7amentos: todas as notifica\u00e7\u00f5es sobre desempenho, consumo de recursos ou regress\u00f5es arquitet\u00f4nicas.<\/h1>\n<p>\nA funcionalidade do n\u00f3 principal do sistema de armazenamento de dados \u00e9 uma das principais tarefas da equipe SRE e de opera\u00e7\u00e3o. A implementa\u00e7\u00e3o de um orquestrador e de uma solu\u00e7\u00e3o de HA baseada em VIP permitiu alcan\u00e7ar os seguintes resultados:<\/p>\n<ul>\n<li>detec\u00e7\u00e3o confi\u00e1vel de problemas de topologia do cluster de BD;\n<\/li>\n<li>resposta autom\u00e1tica e r\u00e1pida a incidentes relacionados ao mestre, o que reduz o tempo de inatividade do sistema.\n<\/li>\n<\/ul>\n<p>\nNo entanto, a solu\u00e7\u00e3o tem suas limita\u00e7\u00f5es e desvantagens:<\/p>\n<ul>\n<li>a escalabilidade do esquema de HA para v\u00e1rios data centers exigir\u00e1 a exist\u00eancia de uma rede L2 unificada entre eles;\n<\/li>\n<li>antes de atribuir VIP ao novo mestre, precisamos liber\u00e1-lo no antigo. O processo \u00e9 sequencial, o que aumenta o tempo de recupera\u00e7\u00e3o;\n<\/li>\n<li>liberar VIP requer acesso SSH ao servidor, ou qualquer outro meio de invocar procedimentos remotos. Como o servidor ou o BD est\u00e1 enfrentando problemas que acionaram o processo de recupera\u00e7\u00e3o, n\u00e3o podemos ter certeza de que a remo\u00e7\u00e3o do VIP ser\u00e1 bem-sucedida. Isso pode levar \u00e0 ocorr\u00eancia de dois servidores com o mesmo endere\u00e7o IP virtual e a um problema <code>split brain<\/code>.\n<\/li>\n<\/ul>\n<p>\nPara evitar <code>split brain<\/code>, pode-se usar o m\u00e9todo <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/STONITH\">STONITH<\/a><\/noindex> ('Shoot The Other Node In The Head'), que isola ou desliga completamente o n\u00f3 problem\u00e1tico. Existem outros m\u00e9todos para implementar alta disponibilidade no cluster: combina\u00e7\u00e3o de VIP e DNS, descoberta de servi\u00e7os e servi\u00e7os proxy, replica\u00e7\u00e3o s\u00edncrona e outros m\u00e9todos, que t\u00eam suas desvantagens e vantagens.<\/p>\n<p>Falei sobre nossa abordagem para criar um cluster MySQL tolerante a falhas. \u00c9 simples de implementar e proporciona um n\u00edvel aceit\u00e1vel de confiabilidade nas condi\u00e7\u00f5es atuais. \u00c0 medida que todo o sistema como um todo e a infraestrutura em particular evolu\u00edrem, essa abordagem certamente tamb\u00e9m evoluir\u00e1.<br \/>\n<br \/>Fonte: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/citymobil\/blog\/491044\/\">habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u0412 \u0421\u0438\u0442\u0438\u043c\u043e\u0431\u0438\u043b \u043c\u044b \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u0435\u043c \u0431\u0430\u0437\u0443 \u0434\u0430\u043d\u043d\u044b\u0445 MySQL \u0432 \u043a\u0430\u0447\u0435\u0441\u0442\u0432\u0435 \u043e\u0441\u043d\u043e\u0432\u043d\u043e\u0433\u043e \u0445\u0440\u0430\u043d\u0438\u043b\u0438\u0449\u0430 \u043f\u043e\u0441\u0442\u043e\u044f\u043d\u043d\u044b\u0445 \u0434\u0430\u043d\u043d\u044b\u0445. \u0423 \u043d\u0430\u0441 \u0435\u0441\u0442\u044c \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u043e \u043a\u043b\u0430\u0441\u0442\u0435\u0440\u043e\u0432 \u0431\u0430\u0437 \u0434\u0430\u043d\u043d\u044b\u0445 \u043f\u043e\u0434 \u0440\u0430\u0437\u043b\u0438\u0447\u043d\u044b\u0435 \u0441\u0435\u0440\u0432\u0438\u0441\u044b \u0438 \u0446\u0435\u043b\u0438. \u041f\u043e\u0441\u0442\u043e\u044f\u043d\u043d\u0430\u044f \u0434\u043e\u0441\u0442\u0443\u043f\u043d\u043e\u0441\u0442\u044c \u043c\u0430\u0441\u0442\u0435\u0440\u0430 \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u043a\u0440\u0438\u0442\u0438\u0447\u0435\u0441\u043a\u0438\u043c \u043f\u043e\u043a\u0430\u0437\u0430\u0442\u0435\u043b\u0435\u043c \u0440\u0430\u0431\u043e\u0442\u043e\u0441\u043f\u043e\u0441\u043e\u0431\u043d\u043e\u0441\u0442\u0438 \u0432\u0441\u0435\u0439 \u0441\u0438\u0441\u0442\u0435\u043c\u044b \u0438 \u0435\u0435 \u043e\u0442\u0434\u0435\u043b\u044c\u043d\u044b\u0445 \u0447\u0430\u0441\u0442\u0435\u0439. \u0410\u0432\u0442\u043e\u043c\u0430\u0442\u0438\u0447\u0435\u0441\u043a\u043e\u0435 \u0432\u043e\u0441\u0441\u0442\u0430\u043d\u043e\u0432\u043b\u0435\u043d\u0438\u0435 \u043a\u043b\u0430\u0441\u0442\u0435\u0440\u0430 \u0432 \u0441\u043b\u0443\u0447\u0430\u0435 \u043e\u0442\u043a\u0430\u0437\u0430 \u043c\u0430\u0441\u0442\u0435\u0440\u0430 \u0441\u0438\u043b\u044c\u043d\u043e \u0441\u043d\u0438\u0436\u0430\u0435\u0442 \u0432\u0440\u0435\u043c\u044f \u0440\u0435\u0430\u0433\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f \u043d\u0430 \u0438\u043d\u0446\u0438\u0434\u0435\u043d\u0442 \u0438 \u0432\u0440\u0435\u043c\u044f \u043f\u0440\u043e\u0441\u0442\u043e\u044f \u0441\u0438\u0441\u0442\u0435\u043c\u044b. [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":82114,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-82113","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.3 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u0412 \u0421\u0438\u0442\u0438\u043c\u043e\u0431\u0438\u043b \u043c\u044b \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u0435\u043c \u0431\u0430\u0437\u0443 \u0434\u0430\u043d\u043d\u044b\u0445 MySQL \u0432 \u043a\u0430\u0447\u0435\u0441\u0442\u0432\u0435 \u043e\u0441\u043d\u043e\u0432\u043d\u043e\u0433\u043e \u0445\u0440\u0430\u043d\u0438\u043b\u0438\u0449\u0430 \u043f\u043e\u0441\u0442\u043e\u044f\u043d\u043d\u044b\u0445 \u0434\u0430\u043d\u043d\u044b\u0445.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/orchestrator-i-vip-kak-ha-reshenie-dlya-klastera-mysql\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.3\" \/>\n\t\t<meta property=\"og:locale\" content=\"pt_PT\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47Orchestrator \u0438 VIP \u043a\u0430\u043a HA-\u0440\u0435\u0448\u0435\u043d\u0438\u0435 \u0434\u043b\u044f \u043a\u043b\u0430\u0441\u0442\u0435\u0440\u0430 MySQL | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u0412 \u0421\u0438\u0442\u0438\u043c\u043e\u0431\u0438\u043b \u043c\u044b \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u0435\u043c \u0431\u0430\u0437\u0443 \u0434\u0430\u043d\u043d\u044b\u0445 MySQL \u0432 \u043a\u0430\u0447\u0435\u0441\u0442\u0432\u0435 \u043e\u0441\u043d\u043e\u0432\u043d\u043e\u0433\u043e \u0445\u0440\u0430\u043d\u0438\u043b\u0438\u0449\u0430 \u043f\u043e\u0441\u0442\u043e\u044f\u043d\u043d\u044b\u0445 \u0434\u0430\u043d\u043d\u044b\u0445.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/orchestrator-i-vip-kak-ha-reshenie-dlya-klastera-mysql\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2020-05-19T11:42:51+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-05-19T11:42:51+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Orchestrator e VIP como solu\u00e7\u00e3o HA para cluster MySQL | ProHoster","description":"Na Sitimobil, usamos o banco de dados MySQL como nosso principal reposit\u00f3rio de dados persistentes.","canonical_url":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/orchestrator-i-vip-kak-ha-reshenie-dlya-klastera-mysql","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"pt_PT","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47Orchestrator \u0438 VIP \u043a\u0430\u043a HA-\u0440\u0435\u0448\u0435\u043d\u0438\u0435 \u0434\u043b\u044f \u043a\u043b\u0430\u0441\u0442\u0435\u0440\u0430 MySQL | ProHoster","og:description":"\u0412 \u0421\u0438\u0442\u0438\u043c\u043e\u0431\u0438\u043b \u043c\u044b \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u0435\u043c \u0431\u0430\u0437\u0443 \u0434\u0430\u043d\u043d\u044b\u0445 MySQL \u0432 \u043a\u0430\u0447\u0435\u0441\u0442\u0432\u0435 \u043e\u0441\u043d\u043e\u0432\u043d\u043e\u0433\u043e \u0445\u0440\u0430\u043d\u0438\u043b\u0438\u0449\u0430 \u043f\u043e\u0441\u0442\u043e\u044f\u043d\u043d\u044b\u0445 \u0434\u0430\u043d\u043d\u044b\u0445.","og:url":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/orchestrator-i-vip-kak-ha-reshenie-dlya-klastera-mysql","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-05-19T11:42:51+00:00","article:modified_time":"2020-05-19T11:42:51+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"82113","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 15:44:23","updated":"2022-09-28 00:08:45","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts\/82113","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/comments?post=82113"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts\/82113\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/media\/82114"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/media?parent=82113"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/categories?post=82113"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/tags?post=82113"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}