{"id":91846,"date":"2020-08-19T19:41:57","date_gmt":"2020-08-19T17:41:57","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/o-pereezde-s-redis-na-redis-cluster"},"modified":"2020-08-19T19:41:57","modified_gmt":"2020-08-19T17:41:57","slug":"o-pereezde-s-redis-na-redis-cluster","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/o-pereezde-s-redis-na-redis-cluster","title":{"rendered":"Sobre la transici\u00f3n de Redis a Redis-cluster","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Sobre la transici\u00f3n de Redis a Redis-cluster\" src=\"\/wp-content\/uploads\/2020\/08\/ea8bc47f73ef3b06ccfdf94d323592bf.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Al tratar con un producto que ha estado en desarrollo durante m\u00e1s de una d\u00e9cada, no es sorprendente encontrarse con tecnolog\u00edas obsoletas. Pero, \u00bfqu\u00e9 pasa si dentro de seis meses debes soportar una carga diez veces mayor y el costo de las ca\u00eddas aumenta cientos de veces? En este caso, necesitas un brillante Ingeniero de Highload. Sin embargo, debido a la falta de uno, la soluci\u00f3n del problema me fue confiada. En la primera parte del art\u00edculo, hablar\u00e9 sobre c\u00f3mo migramos de Redis a Redis-cluster, y en la segunda parte, dar\u00e9 consejos sobre c\u00f3mo comenzar a usar el cl\u00faster y qu\u00e9 aspectos tener en cuenta al operarlo.<\/p>\n<p><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h1 id=\"vybor-tehnologii\">Selecci\u00f3n de tecnolog\u00eda<\/h1>\n<p><\/p>\n<p>\u00bfEs tan malo <em>Redis independiente<\/em> (standalone redis) en una configuraci\u00f3n con 1 maestro y N esclavos? \u00bfPor qu\u00e9 lo llamo una tecnolog\u00eda obsoleta?<\/p>\n<p><\/p>\n<blockquote><p>No, Redis no es tan malo... Sin embargo, hay algunas fallas que no se pueden ignorar.<\/p><\/blockquote>\n<p><\/p>\n<ul>\n<li>\n<p>En primer lugar, Redis no soporta mecanismos de recuperaci\u00f3n ante la ca\u00edda del maestro. Para solucionar este problema, utilizamos una configuraci\u00f3n con conmutaci\u00f3n autom\u00e1tica de VIP a un nuevo maestro, cambiando el rol de uno de los esclavos y alternando el resto. Este mecanismo funcion\u00f3, pero no se pod\u00eda considerar una soluci\u00f3n confiable. En primer lugar, ocurrieron falsos disparos, y en segundo lugar, era una soluci\u00f3n temporaria que requer\u00eda acciones manuales despu\u00e9s del disparo.<\/p>\n<p>\n<\/li>\n<li>\n<p>En segundo lugar, tener solo un maestro llevaba a problemas de particionado. Era necesario crear varios cl\u00fasteres independientes de \"1 maestro y N esclavos\", luego distribuir manualmente las bases de datos en estas m\u00e1quinas y esperar que al d\u00eda siguiente una de las bases no crezca tanto que tenga que ser trasladada a una instancia separada.<\/p>\n<p>\n<\/li>\n<\/ul>\n<p><\/p>\n<p>\u00bfCu\u00e1les son las opciones?<\/p>\n<p><\/p>\n<ul>\n<li>La opci\u00f3n m\u00e1s cara y completa es Redis-Enterprise. Esta es una soluci\u00f3n empaquetada con soporte t\u00e9cnico completo. A pesar de que parece ideal desde el punto de vista t\u00e9cnico, no nos sirvi\u00f3 por razones ideol\u00f3gicas. <\/li>\n<li>Redis-cluster. Esta opci\u00f3n incluye soporte para conmutaci\u00f3n por error del maestro y particionado. La interfaz pr\u00e1cticamente no difiere de la versi\u00f3n est\u00e1ndar. Se ve prometedora; hablaremos de las trampas m\u00e1s adelante.<\/li>\n<li>Tarantool, Memcache, Aerospike y otros. Todas estas herramientas hacen aproximadamente lo mismo. Pero cada una tiene sus desventajas. Decidimos no poner todos los huevos en una sola canasta. Usamos Memcache y Tarantool para otras tareas, y, adelant\u00e1ndome, dir\u00e9 que en nuestra pr\u00e1ctica hemos tenido m\u00e1s problemas con ellos.<\/li>\n<\/ul>\n<p><\/p>\n<h1 id=\"specifika-ispolzovaniya\">Especificidad del uso<\/h1>\n<p><\/p>\n<p>Veamos qu\u00e9 tareas hemos resuelto hist\u00f3ricamente con Redis y qu\u00e9 funcionalidades hemos utilizado:<\/p>\n<p><\/p>\n<ul>\n<li>Cach\u00e9 antes de solicitudes a servicios remotos como 2GIS | Golang<br \/>\n<blockquote><p>GET SET MGET MSET \"SELECCIONAR DB\"\n<\/p><\/blockquote>\n<\/li>\n<li>Cach\u00e9 antes de MYSQL | PHP<br \/>\n<blockquote><p>GET SET MGET MSET SCAN \"CLAVE POR PATR\u00d3N\" \"SELECCIONAR DB\"\n<\/p><\/blockquote>\n<\/li>\n<li>Almacenamiento principal para el servicio de gesti\u00f3n de sesiones y coordenadas de conductores | Golang<br \/>\n<blockquote><p>GET SET MGET MSET \"SELECCIONAR DB\" \"A\u00d1ADIR CLAVE GEO\" \"OBTENER CLAVE GEO\" SCAN\n<\/p><\/blockquote>\n<\/li>\n<\/ul>\n<p><\/p>\n<p>Como pueden ver, no hay matem\u00e1ticas superiores. \u00bfCu\u00e1l es entonces la complejidad? Analicemos cada m\u00e9todo por separado.<\/p>\n<p><\/p>\n<p>El m\u00e9todo<br \/>\nDescripci\u00f3n<br \/>\nParticularidades de Redis-cluster<br \/>\nSoluci\u00f3n<\/p>\n<p>GET SET<br \/>\nEscribir\/leer clave<\/p>\n<p>MGET MSET<br \/>\nEscribir\/leer varias claves<br \/>\nLas claves estar\u00e1n en diferentes nodos. Las bibliotecas listas para usar pueden hacer operaciones m\u00faltiples solo dentro de un nodo.<br \/>\nReemplazar MGET por un pipeline de N operaciones GET<\/p>\n<p>SELECT DB<br \/>\nSeleccionar la base de datos con la que vamos a trabajar<br \/>\nNo soporta varias bases de datos<br \/>\nAlmacenar todo en una sola base. Agregar prefijos a las claves<\/p>\n<p>SCAN<br \/>\nRecorrer todas las claves en la base<br \/>\nDado que tenemos una sola base, recorrer todas las claves en el cl\u00faster es demasiado costoso<br \/>\nMantener la invariante dentro de una clave y hacer HSCAN por esa clave. O renunciar por completo.<\/p>\n<p>GEO<br \/>\nOperaciones de trabajo con claves geogr\u00e1ficas<br \/>\nLa clave geogr\u00e1fica no se fragmenta<\/p>\n<p>KEY BY PATTERN<br \/>\nBuscar clave por patr\u00f3n<br \/>\nDado que tenemos una sola base, buscaremos en todas las claves del cl\u00faster. Es demasiado costoso.<br \/>\nRenunciar o mantener la invariante, como en el caso de SCAN.<\/p>\n<p><\/p>\n<h1 id=\"redis-vs-redis-cluster\">Redis vs Redis-cluster<\/h1>\n<p><\/p>\n<p>\u00bfQu\u00e9 perdemos y qu\u00e9 ganamos al pasar a un cl\u00faster?<\/p>\n<p><\/p>\n<ul>\n<li>Desventajas: perdemos la funcionalidad de varias bases de datos. \n<ul>\n<li>Si queremos almacenar datos l\u00f3gicamente no relacionados en un solo cl\u00faster, tendremos que hacer adaptaciones en forma de prefijos. <\/li>\n<li>Perdemos todas las operaciones \"por base\", como SCAN, DBSIZE, CLEAR DB, etc.<\/li>\n<li>Las operaciones m\u00faltiples se han vuelto significativamente m\u00e1s complicadas de implementar, ya que puede requerirse acceso a varios nodos.<\/li>\n<\/ul>\n<\/li>\n<li>Ventajas: \n<ul>\n<li>Tolerancia a fallos en forma de failover del maestro.<\/li>\n<li>Fragmentaci\u00f3n del lado de Redis.<\/li>\n<li>Movimiento de datos entre nodos de forma at\u00f3mica y sin interrupciones.<\/li>\n<li>Adici\u00f3n y redistribuci\u00f3n de recursos y cargas sin interrupciones.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<p><\/p>\n<p><em>Llegar\u00eda a la conclusi\u00f3n de que si no necesitas garantizar un alto nivel de disponibilidad, entonces no vale la pena migrar a un cl\u00faster, ya que puede ser una tarea no trivial. Pero si inicialmente hay que elegir entre una versi\u00f3n independiente y un cl\u00faster, es mejor optar por el cl\u00faster, ya que no es en absoluto peor y adem\u00e1s te quitar\u00e1 parte del dolor de cabeza.<\/em><\/p>\n<p><\/p>\n<h1 id=\"podgotovka-k-pereezdu\">Preparaci\u00f3n para la migraci\u00f3n<\/h1>\n<p><\/p>\n<p>Comencemos con los requisitos de la migraci\u00f3n:<\/p>\n<p><\/p>\n<ul>\n<li>Debe ser sin interrupciones. No estamos de acuerdo con detener el servicio por completo durante 5 minutos.<\/li>\n<li>Debe ser lo m\u00e1s seguro y gradual posible. Queremos tener cierto control sobre la situaci\u00f3n. No deseamos lanzar todo de golpe y rezar por un bot\u00f3n de reversi\u00f3n.<\/li>\n<li>M\u00ednimas p\u00e9rdidas de datos durante la migraci\u00f3n. Entendemos que ser\u00e1 muy dif\u00edcil migrar de forma at\u00f3mica, por lo que permitimos cierta desincronizaci\u00f3n entre los datos en Redis normal y en el cl\u00faster.<\/li>\n<\/ul>\n<p><\/p>\n<h1 id=\"obsluzhivanie-klastera\">Mantenimiento del cl\u00faster<\/h1>\n<p><\/p>\n<p>Antes de la migraci\u00f3n, debemos considerar si podemos mantener el cl\u00faster:<\/p>\n<p><\/p>\n<ul>\n<li>Gr\u00e1ficas. Utilizamos Prometheus y Grafana para gr\u00e1ficos de carga de CPU, memoria ocupada, n\u00famero de clientes, cantidad de operaciones GET, SET, AUTH, etc.<\/li>\n<li>Experiencia. Imagina que ma\u00f1ana estar\u00e1s a cargo de un enorme cl\u00faster. Si se rompe, nadie m\u00e1s que t\u00fa podr\u00e1 repararlo. Si comienza a relentizarse, todos vendr\u00e1n a ti. Si necesitas agregar recursos o redistribuir la carga, volver\u00e1n a ti. Para no encanecer a los 25, es recomendable prever estos casos y verificar de antemano c\u00f3mo se comportar\u00e1 la tecnolog\u00eda en tales o cuales acciones. Hablaremos de esto con m\u00e1s detalle en la secci\u00f3n 'Experiencia'.<\/li>\n<li>Monitoreos y alertas. Cuando se rompe el cl\u00faster, queremos enterarnos primero. Aqu\u00ed nos limitamos a alertar que todos los nodos devuelven la misma informaci\u00f3n sobre el estado del cl\u00faster (s\u00ed, a veces es diferente). Y otros problemas se notan m\u00e1s r\u00e1pidamente a trav\u00e9s de las alertas de los servicios clientes de Redis.<\/li>\n<\/ul>\n<p><\/p>\n<h1 id=\"pereezd\">Mudanza<\/h1>\n<p><\/p>\n<p>C\u00f3mo vamos a migrar:<\/p>\n<p><\/p>\n<ul>\n<li>En primer lugar, es necesario preparar la biblioteca para trabajar con el cl\u00faster. Como base para la versi\u00f3n en Go, tomamos go-redis y lo modificamos ligeramente. Implementamos m\u00e9todos Multi a trav\u00e9s de pipelines, y tambi\u00e9n ajustamos un poco las reglas de repetici\u00f3n de solicitudes. Con la versi\u00f3n para PHP surgieron m\u00e1s problemas, pero al final nos decantamos por php-redis. Recientemente implementaron soporte para cl\u00fasteres, y a nuestro parecer, luce bien.<\/li>\n<li>A continuaci\u00f3n, necesitamos desplegar el cl\u00faster. Esto se hace literalmente en dos comandos basados en el archivo de configuraci\u00f3n. Hablaremos m\u00e1s sobre la configuraci\u00f3n m\u00e1s adelante.<\/li>\n<li>Para la transici\u00f3n gradual, utilizamos el modo dry. Como tenemos dos versiones de la biblioteca con la misma interfaz (una para la versi\u00f3n normal y otra para el cl\u00faster), no es dif\u00edcil hacer una envoltura que funcione con la versi\u00f3n separada y que paralelamente duplique todas las solicitudes al cl\u00faster, compare las respuestas y registre las discrepancias en los logs (en nuestro caso, en NewRelic). As\u00ed, incluso si al desplegar la versi\u00f3n del cl\u00faster falla, nuestra producci\u00f3n no se ver\u00e1 afectada. <\/li>\n<li>Al desplegar el cl\u00faster en modo dry, podemos observar tranquilamente el gr\u00e1fico de discrepancias en las respuestas. Si la tasa de errores avanza lenta pero seguramente hacia alguna constante peque\u00f1a, significa que todo est\u00e1 bien. \u00bfPor qu\u00e9 siguen habiendo discrepancias? Porque la escritura en la versi\u00f3n separada ocurre un poco antes que en el cl\u00faster, y debido a un micro-retraso, los datos pueden diferirse. Solo queda revisar los logs de discrepancias, y si todas son explicables por la no atomicidad de la escritura, podemos seguir adelante.<\/li>\n<li>Ahora podemos alternar el modo dry en sentido inverso. Escribiremos y leeremos del cl\u00faster, y duplicaremos en la versi\u00f3n separada. \u00bfPor qu\u00e9? Durante la pr\u00f3xima semana queremos observar el funcionamiento del cl\u00faster. Si descubrimos que en picos de carga hay problemas, o si hemos pasado por alto algo, siempre tenemos un retroceso de emergencia al c\u00f3digo anterior y a los datos actuales gracias al modo dry.<\/li>\n<li>Solo queda desactivar el modo dry y desmantelar la versi\u00f3n separada. <\/li>\n<\/ul>\n<p><\/p>\n<h1 id=\"ekspertiza\">Examen<\/h1>\n<p><\/p>\n<p>Primero, una breve descripci\u00f3n de la estructura del cl\u00faster.<\/p>\n<p><\/p>\n<p>En primer lugar, Redis es un almacenamiento key-value. Se utilizan cadenas arbitrarias como claves. Los valores pueden ser n\u00fameros, cadenas y estructuras enteras. Hay una gran cantidad de estas \u00faltimas, pero para entender la estructura general, eso no es importante.<br \/>\nEl siguiente nivel de abstracci\u00f3n despu\u00e9s de las claves son los slots (SLOTS). Cada clave pertenece a uno de los 16 383 slots. Dentro de cada slot puede haber tantas claves como se desee. As\u00ed, todas las claves se dividen en 16 383 conjuntos no superpuestos.<br \/>\n<img decoding=\"async\" alt=\"Sobre la transici\u00f3n de Redis a Redis-cluster\" src=\"\/wp-content\/uploads\/2020\/08\/a5e4be23381b42287f693e01d5d59a99.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>A continuaci\u00f3n, debe haber N nodos maestros en el cl\u00faster. Cada nodo se puede considerar como una instancia separada de Redis, que conoce todo sobre otros nodos dentro del cl\u00faster. Cada nodo maestro contiene una cierta cantidad de slots. Cada slot pertenece \u00fanicamente a un nodo maestro. Todos los slots deben distribuirse entre los nodos. Si hay slots no distribuidos, las claves almacenadas en ellos no estar\u00e1n disponibles. Cada nodo maestro tiene sentido ejecutarlo en una m\u00e1quina l\u00f3gica o f\u00edsica separada. Tambi\u00e9n hay que recordar que cada nodo funciona solo en un n\u00facleo, y si desea ejecutar varias instancias de Redis en una misma m\u00e1quina l\u00f3gica, aseg\u00farese de que funcionen en n\u00facleos diferentes (no hemos probado esto, pero en teor\u00eda deber\u00eda funcionar). En esencia, los nodos maestros proporcionan un sharding normal, y un mayor n\u00famero de nodos maestros permite escalar las consultas de escritura y lectura.<\/p>\n<p><\/p>\n<p>Despu\u00e9s de que todas las claves se hayan distribuido entre los slots y los slots se hayan esparcido entre los nodos maestros, se pueden agregar a cada nodo maestro una cantidad arbitraria de nodos esclavos. Dentro de cada conjunto de \"maestro-esclavo\" funcionar\u00e1 una replicaci\u00f3n normal. Los esclavos son necesarios para escalar las consultas de lectura y para el failover en caso de que falle el maestro.<br \/>\n<img decoding=\"async\" alt=\"Sobre la transici\u00f3n de Redis a Redis-cluster\" src=\"\/wp-content\/uploads\/2020\/08\/90feb7ef9dacb858d5f21edc214df14d.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Ahora hablemos de las operaciones que ser\u00eda bueno saber hacer.<\/p>\n<p><\/p>\n<p>Accederemos al sistema a trav\u00e9s de Redis-CLI. Dado que Redis no tiene un \u00fanico punto de entrada, se pueden realizar las siguientes operaciones en cualquiera de los nodos. En cada punto, hago hincapi\u00e9 en la posibilidad de realizar la operaci\u00f3n bajo carga.<\/p>\n<p><\/p>\n<ul>\n<li>Lo primero y m\u00e1s importante que necesitaremos: la operaci\u00f3n cluster nodes. Esta devuelve el estado del cl\u00faster, muestra la lista de nodos, sus roles, la distribuci\u00f3n de slots, etc. Se pueden obtener m\u00e1s detalles mediante cluster info y cluster slots.<\/li>\n<li>Ser\u00eda \u00fatil poder a\u00f1adir y eliminar nodos. Para ello existen las operaciones cluster meet y cluster forget. Tenga en cuenta que es necesario aplicar cluster forget a CADA nodo, tanto a los maestros como a las r\u00e9plicas. Mientras que cluster meet solo se necesita invocar en un nodo. Esta diferencia puede ser desconcertante, por lo que es mejor conocerla antes de poner en producci\u00f3n el cl\u00faster. La adici\u00f3n de un nodo se realiza de forma segura en combate y no afecta el funcionamiento del cl\u00faster (lo que tiene sentido). Sin embargo, si planea eliminar un nodo del cl\u00faster, debe asegurarse de que no queden ranuras en \u00e9l (de lo contrario, corre el riesgo de perder el acceso a todas las claves en ese nodo). Adem\u00e1s, no elimine un maestro que tenga esclavos, de lo contrario, se llevar\u00e1 a cabo una votaci\u00f3n innecesaria por un nuevo maestro. Si ya no hay ranuras en los nodos, eso es un peque\u00f1o problema, pero \u00bfpor qu\u00e9 deber\u00edamos tener elecciones innecesarias si podemos eliminar primero a los esclavos?<\/li>\n<li>Si necesita forzar el cambio entre maestro y esclavo, puede usar el comando cluster failover. Al invocarlo en combate, es importante entender que durante la ejecuci\u00f3n de la operaci\u00f3n, el maestro no estar\u00e1 disponible. Normalmente, el cambio se produce en menos de un segundo, pero no es at\u00f3mico. Puede esperar que parte de las solicitudes al maestro falle en ese tiempo.<\/li>\n<li>Antes de eliminar un nodo del cl\u00faster, no deber\u00eda haber slots restantes en \u00e9l. Es mejor redistribuirlos utilizando el comando cluster reshard. Los slots se trasladar\u00e1n de un maestro a otro. La operaci\u00f3n puede tardar varios minutos, dependiendo del volumen de datos que se transfieren; sin embargo, el proceso de transferencia es seguro y no afecta al funcionamiento del cl\u00faster. De este modo, todos los datos pueden trasladarse de un nodo a otro bajo carga, sin preocuparse por su disponibilidad. Sin embargo, hay detalles a considerar. Primero, la transferencia de datos conlleva cierta carga en el nodo receptor y en el emisor. Si el nodo receptor ya est\u00e1 muy cargado en t\u00e9rminos de CPU, no deber\u00eda sobrecargarse m\u00e1s con la recepci\u00f3n de nuevos datos. En segundo lugar, tan pronto como no queden slots en el maestro-emisor, todos sus esclavos pasar\u00e1n inmediatamente al maestro al que se trasladaron esos slots. Y el problema es que todos esos esclavos querr\u00e1n sincronizar los datos al mismo tiempo. Y tendr\u00e1s suerte si se trata de una sincronizaci\u00f3n parcial en lugar de una completa. Ten esto en cuenta y combina las operaciones de transferencia de slots y de desconexi\u00f3n\/transporte de esclavos. O bien, espera que tengas un margen de seguridad suficiente.<\/li>\n<li>\u00bfQu\u00e9 hacer si al trasladar notas te das cuenta de que has perdido slots en alg\u00fan lugar? Espero que este problema no te afecte, pero si lo hace, hay una operaci\u00f3n llamada cluster fix. Esta operaci\u00f3n distribuir\u00e1 los slots entre los nodos de manera aleatoria. Te recomiendo verificar su funcionamiento eliminando previamente del cl\u00faster el nodo con los slots distribuidos. Dado que los datos en los slots no distribuidos ya no est\u00e1n disponibles, ya es tarde para preocuparse por los problemas de disponibilidad de esos slots. Por su parte, la operaci\u00f3n no afectar\u00e1 a los slots distribuidos.<\/li>\n<li>Otra operaci\u00f3n \u00fatil es monitor. Esta permite ver en tiempo real toda la lista de solicitudes que llegan al nodo. Adem\u00e1s, se puede utilizar grep para averiguar si hay tr\u00e1fico necesario.<\/li>\n<\/ul>\n<p><\/p>\n<p>Tambi\u00e9n vale la pena mencionar el procedimiento de conmutaci\u00f3n por error del maestro. En resumen, existe y, en mi opini\u00f3n, funciona maravillosamente. Sin embargo, no se debe pensar que si se desconecta la m\u00e1quina del nodo maestro, Redis cambiar\u00e1 instant\u00e1neamente y los clientes no notar\u00e1n la p\u00e9rdida. En mi experiencia, el cambio tarda unos segundos. Durante este tiempo, parte de los datos no estar\u00e1 disponible: se detecta la falta del maestro, los nodos votan por uno nuevo, los esclavos se cambian, los datos se sincronizan. La mejor manera de asegurarse de que el esquema funciona es realizar simulacros locales. Levante el cl\u00faster en su computadora port\u00e1til, d\u00e9 una carga m\u00ednima, simule una ca\u00edda (por ejemplo, bloqueando puertos) y eval\u00fae la velocidad de conmutaci\u00f3n. En mi opini\u00f3n, solo jugando de esta manera durante uno o dos d\u00edas se puede estar seguro de que la tecnolog\u00eda funciona. O, por lo menos, esperar que el software que usa la mitad de internet funcione sin problemas.<\/p>\n<p><\/p>\n<h1 id=\"konfiguraciya\">Configuraci\u00f3n<\/h1>\n<p><\/p>\n<p>A menudo, la configuraci\u00f3n es lo primero que se necesita para comenzar a trabajar con la herramienta. Y cuando todo ya est\u00e1 funcionando, no se quiere tocar la configuraci\u00f3n. Se requieren ciertos esfuerzos para obligarse a volver a los ajustes y revisarlos a fondo. En mi memoria, hemos tenido al menos dos graves fallos debido a la falta de atenci\u00f3n a la configuraci\u00f3n. Preste especial atenci\u00f3n a los siguientes puntos:<\/p>\n<p><\/p>\n<ul>\n<li>timeout 0<br \/>\n<em>El tiempo despu\u00e9s del cual se cierran las conexiones inactivas (en segundos). 0 significa que no se cierran.<\/em><br \/>\nNo todas nuestras bibliotecas sab\u00edan cerrar correctamente las conexiones. Al desactivar esta configuraci\u00f3n, corremos el riesgo de alcanzar el l\u00edmite de n\u00famero de clientes. Por otro lado, si hay tal problema, la desconexi\u00f3n autom\u00e1tica de conexiones perdidas lo disimular\u00e1 y podr\u00eda no notarlo. Adem\u00e1s, no se debe activar esta configuraci\u00f3n al usar conexiones persistentes.<\/li>\n<li>Save x y &amp; appendonly yes<br \/>\n<em>Guardado de un snapshot RDB.<\/em><br \/>\nLos problemas con RDB\/AOF los discutiremos en detalle m\u00e1s adelante.<\/li>\n<li>stop-writes-on-bgsave-error no &amp; slave-serve-stale-data yes<br \/>\n<em>Si est\u00e1 activado, cuando hay un fallo en el snapshot RDB, el maestro dejar\u00e1 de aceptar solicitudes de modificaci\u00f3n. Si se pierde la conexi\u00f3n con el maestro, el esclavo puede seguir respondiendo a las solicitudes (s\u00ed). O puede dejar de responder (no).<\/em><br \/>\nNo estamos satisfechos con la situaci\u00f3n en la que Redis se convierte en una calabaza.<\/li>\n<li>repl-ping-slave-period 5<br \/>\n<em>Despu\u00e9s de este per\u00edodo de tiempo, comenzaremos a preocuparnos por la posibilidad de que el maestro haya fallado y que sea hora de realizar el procedimiento de failover.<\/em><br \/>\nTendremos que encontrar manualmente un equilibrio entre las falsas alarmas y el inicio del failover. En nuestra experiencia, esto es 5 segundos.<\/li>\n<li>repl-backlog-size 1024mb &amp; epl-backlog-ttl 0<br \/>\n<em>Exactamente la cantidad de datos que podemos almacenar en el b\u00fafer para la r\u00e9plica ca\u00edda. Si el b\u00fafer se agota, tendremos que sincronizarnos completamente.<\/em><br \/>\nLa pr\u00e1ctica sugiere que es mejor establecer un valor m\u00e1s alto. Las razones por las que la r\u00e9plica puede comenzar a quedarse atr\u00e1s son numerosas. Si se queda atr\u00e1s, lo m\u00e1s probable es que su maestro ya tenga dificultades, y la sincronizaci\u00f3n completa ser\u00e1 la gota que colme el vaso.<\/li>\n<li>maxclients 10000<br \/>\n<em>N\u00famero m\u00e1ximo de clientes simult\u00e1neos.<\/em><br \/>\nPor nuestra experiencia, es mejor establecer un valor m\u00e1s alto. Redis maneja muy bien 10,000 conexiones. Solo aseg\u00farese de que el sistema tenga suficientes sockets. <\/li>\n<li>maxmemory-policy volatile-ttl<br \/>\n<em>Regla bajo la cual se eliminan las claves al alcanzar el l\u00edmite de memoria disponible.<\/em><br \/>\nAqu\u00ed lo importante no es la regla en s\u00ed, sino comprender c\u00f3mo va a suceder esto. Hay que elogiar a Redis por su capacidad para funcionar normalmente al alcanzar el l\u00edmite de memoria. <\/li>\n<\/ul>\n<p><\/p>\n<h1 id=\"problemy-rdb-i-aof\">Problemas de RDB y AOF<\/h1>\n<p><\/p>\n<p>Aunque Redis almacena toda la informaci\u00f3n en la memoria RAM, tambi\u00e9n hay un mecanismo para guardarla en disco. M\u00e1s precisamente, hay tres mecanismos:<\/p>\n<p><\/p>\n<ul>\n<li>RDB-snapshot \u2014 un volcado completo de todos los datos. Se establece mediante la configuraci\u00f3n SAVE X Y y se lee como 'Guardar un volcado completo de todos los datos cada X segundos, si al menos Y claves han cambiado'.<\/li>\n<li>Archivo de solo anexado \u2014 lista de operaciones en el orden en que se ejecutaron. Agrega las nuevas operaciones llegadas al archivo cada X segundos o cada Y operaciones.<\/li>\n<li>RDB y AOF \u2014 combinaci\u00f3n de los dos anteriores.<\/li>\n<\/ul>\n<p><\/p>\n<p>Todos los m\u00e9todos tienen sus ventajas y desventajas, no voy a enumerarlas todas, solo se\u00f1alar\u00e9 los puntos que me parecen poco obvios.<\/p>\n<p><\/p>\n<p>En primer lugar, para guardar un volcado RDB se requiere llamar a FORK. Si hay muchos datos, esto puede hacer que todo Redis se congele durante un per\u00edodo que va de unos pocos milisegundos a un segundo. Adem\u00e1s, el sistema necesita reservar memoria para dicho volcado, lo que lleva a la necesidad de mantener en la m\u00e1quina l\u00f3gica un doble suministro de memoria RAM: si Redis tiene asignados 8 GB, entonces en la m\u00e1quina virtual con \u00e9l debe haber 16 GB disponibles.<\/p>\n<p><\/p>\n<p>En segundo lugar, hay problemas con la sincronizaci\u00f3n parcial. En modo AOF, al reconectar el esclavo, en lugar de sincronizaci\u00f3n parcial puede realizarse una sincronizaci\u00f3n completa. No he podido entender por qu\u00e9 sucede esto. Pero es importante tenerlo en cuenta.<\/p>\n<p><\/p>\n<p>Estos dos puntos ya nos hacen cuestionar si realmente necesitamos estos datos en disco, dado que ya est\u00e1n duplicados por los esclavos. Solo se pueden perder datos si todos los esclavos fallan, y eso es un problema de nivel \"incendio en el centro de datos\". Como compromiso, se podr\u00eda proponer guardar datos solo en los esclavos, pero en ese caso hay que asegurarse de que esos esclavos nunca se conviertan en maestros durante la recuperaci\u00f3n de emergencia (para esto hay una configuraci\u00f3n de prioridad para los esclavos en su configuraci\u00f3n). En cada caso espec\u00edfico, consideramos si es necesario guardar datos en disco, y la mayor\u00eda de las veces respondemos \"no.\"<\/p>\n<p><\/p>\n<h1 id=\"zaklyuchenie\">Conclusi\u00f3n<\/h1>\n<p><\/p>\n<p>En conclusi\u00f3n, espero haber dado una idea general sobre el funcionamiento de redis-cluster a quienes no lo conoc\u00edan, as\u00ed como haber se\u00f1alado algunos aspectos que pueden no ser obvios para quienes ya lo utilizan desde hace tiempo.<br \/>\nGracias por su tiempo y, como siempre, se agradecen los comentarios sobre el tema.<\/p>\n<p>Fuente: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/citymobil\/blog\/515620\/\">habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041f\u0440\u0438\u0445\u043e\u0434\u044f \u0432 \u043f\u0440\u043e\u0434\u0443\u043a\u0442, \u043a\u043e\u0442\u043e\u0440\u044b\u0439 \u0440\u0430\u0437\u0432\u0438\u0432\u0430\u0435\u0442\u0441\u044f \u0431\u043e\u043b\u044c\u0448\u0435 \u0434\u0435\u0441\u044f\u0442\u043a\u0430 \u043b\u0435\u0442, \u0441\u043e\u0432\u0435\u0440\u0448\u0435\u043d\u043d\u043e \u043d\u0435 \u0443\u0434\u0438\u0432\u0438\u0442\u0435\u043b\u044c\u043d\u043e \u0432\u0441\u0442\u0440\u0435\u0442\u0438\u0442\u044c \u0432 \u043d\u0435\u043c \u0443\u0441\u0442\u0430\u0440\u0435\u0432\u0448\u0438\u0435 \u0442\u0435\u0445\u043d\u043e\u043b\u043e\u0433\u0438\u0438. \u041d\u043e \u0447\u0442\u043e \u0435\u0441\u043b\u0438 \u0447\u0435\u0440\u0435\u0437 \u043f\u043e\u043b\u0433\u043e\u0434\u0430 \u0432\u044b \u0434\u043e\u043b\u0436\u043d\u044b \u0434\u0435\u0440\u0436\u0430\u0442\u044c \u043d\u0430\u0433\u0440\u0443\u0437\u043a\u0443 \u0432 10 \u0440\u0430\u0437 \u0432\u044b\u0448\u0435, \u0430 \u0446\u0435\u043d\u0430 \u043f\u0430\u0434\u0435\u043d\u0438\u0439 \u0443\u0432\u0435\u043b\u0438\u0447\u0438\u0442\u0441\u044f \u0432 \u0441\u043e\u0442\u043d\u0438 \u0440\u0430\u0437? \u0412 \u044d\u0442\u043e\u043c \u0441\u043b\u0443\u0447\u0430\u0435 \u0432\u0430\u043c \u043d\u0435\u043e\u0431\u0445\u043e\u0434\u0438\u043c \u043a\u0440\u0443\u0442\u043e\u0439 Highload Engineer. \u041d\u043e \u0437\u0430 \u043d\u0435\u0438\u043c\u0435\u043d\u0438\u0435\u043c \u0433\u043e\u0440\u043d\u0438\u0447\u043d\u043e\u0439 \u0442\u0430\u043a\u043e\u0432\u043e\u0433\u043e, \u0440\u0435\u0448\u0430\u0442\u044c \u043f\u0440\u043e\u0431\u043b\u0435\u043c\u0443 \u0434\u043e\u0432\u0435\u0440\u0438\u043b\u0438 \u043c\u043d\u0435. \u0412 \u043f\u0435\u0440\u0432\u043e\u0439 [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":91847,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-91846","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.2 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u041f\u0440\u0438\u0445\u043e\u0434\u044f \u0432 \u043f\u0440\u043e\u0434\u0443\u043a\u0442, \u043a\u043e\u0442\u043e\u0440\u044b\u0439 \u0440\u0430\u0437\u0432\u0438\u0432\u0430\u0435\u0442\u0441\u044f \u0431\u043e\u043b\u044c\u0448\u0435.\" \/>\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\/es\/blog\/administrirovanie\/o-pereezde-s-redis-na-redis-cluster\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.2\" \/>\n\t\t<meta property=\"og:locale\" content=\"es_ES\" \/>\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\udd47\u041e \u043f\u0435\u0440\u0435\u0435\u0437\u0434\u0435 \u0441 Redis \u043d\u0430 Redis-cluster | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u041f\u0440\u0438\u0445\u043e\u0434\u044f \u0432 \u043f\u0440\u043e\u0434\u0443\u043a\u0442, \u043a\u043e\u0442\u043e\u0440\u044b\u0439 \u0440\u0430\u0437\u0432\u0438\u0432\u0430\u0435\u0442\u0441\u044f \u0431\u043e\u043b\u044c\u0448\u0435.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/o-pereezde-s-redis-na-redis-cluster\" \/>\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-08-19T17:41:57+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-08-19T17:41:57+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\udd47Sobre la transici\u00f3n de Redis a Redis-cluster | ProHoster","description":"Al entrar en un producto que evoluciona m\u00e1s.","canonical_url":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/o-pereezde-s-redis-na-redis-cluster","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"es_ES","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\udd47\u041e \u043f\u0435\u0440\u0435\u0435\u0437\u0434\u0435 \u0441 Redis \u043d\u0430 Redis-cluster | ProHoster","og:description":"\u041f\u0440\u0438\u0445\u043e\u0434\u044f \u0432 \u043f\u0440\u043e\u0434\u0443\u043a\u0442, \u043a\u043e\u0442\u043e\u0440\u044b\u0439 \u0440\u0430\u0437\u0432\u0438\u0432\u0430\u0435\u0442\u0441\u044f \u0431\u043e\u043b\u044c\u0448\u0435.","og:url":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/o-pereezde-s-redis-na-redis-cluster","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-08-19T17:41:57+00:00","article:modified_time":"2020-08-19T17:41:57+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"91846","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 12:19:41","updated":"2022-10-03 14:54:15","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts\/91846","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/comments?post=91846"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts\/91846\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media\/91847"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media?parent=91846"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/categories?post=91846"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/tags?post=91846"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}