{"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\/en\/blog\/administrirovanie\/o-pereezde-s-redis-na-redis-cluster","title":{"rendered":"On the transition from Redis to Redis-cluster","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"On the transition from Redis to Redis-cluster\" src=\"\/wp-content\/uploads\/2020\/08\/ea8bc47f73ef3b06ccfdf94d323592bf.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>When you come to a product that has been evolving for over a decade, it\u2019s not surprising to encounter outdated technologies. But what if in six months you need to handle a load ten times greater, and the cost of outages increases exponentially? In this case, you will need a skilled Highload Engineer. However, in the absence of such a professional, the problem was entrusted to me. In the first part of this article, I will explain how we migrated from Redis to Redis Cluster, and in the second part, I will provide tips on how to start using the cluster and what to pay attention to during operation.<\/p>\n<p><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h1 id=\"vybor-tehnologii\">Technology Selection<\/h1>\n<p><\/p>\n<p>How bad is <em>standalone Redis<\/em> (standalone redis) in a configuration of 1 master and N slaves? Why do I call it an outdated technology?<\/p>\n<p><\/p>\n<blockquote><p>No, Redis isn\u2019t that bad\u2026 However, there are some drawbacks that cannot be ignored.<\/p><\/blockquote>\n<p><\/p>\n<ul>\n<li>\n<p>Firstly, Redis does not support failover mechanisms for master failures. To address this issue, we implemented a configuration that automatically transfers VIPs to the new master, changes the role of one of the slaves, and switches the rest. This mechanism worked, but it couldn\u2019t be considered a reliable solution. For one, there were false triggers, and secondly, it was one-time use only, requiring manual intervention to reset the system afterward.<\/p>\n<p>\n<\/li>\n<li>\n<p>Secondly, the presence of only one master led to sharding problems. We had to create several independent clusters of '1 master and N slaves', then manually distribute databases across these machines and hope that one of the databases wouldn\u2019t bloat to the point of needing to be moved to a separate instance.<\/p>\n<p>\n<\/li>\n<\/ul>\n<p><\/p>\n<p>What are the options?<\/p>\n<p><\/p>\n<ul>\n<li>The most expensive and feature-rich solution is Redis Enterprise. This is a packaged solution with full technical support. Despite appearing technically perfect, it did not align with our ideological preferences. <\/li>\n<li>Redis Cluster. Out of the box, it supports master failover and sharding. The interface is almost identical to the standard version. It looks promising; we will discuss the pitfalls shortly.<\/li>\n<li>Tarantool, Memcache, Aerospike, and others. All these tools essentially perform the same function. However, each has its shortcomings. We decided not to put all our eggs in one basket. We use Memcache and Tarantool for other tasks, and I\u2019ll say in advance that in our experience, we faced more issues with them.<\/li>\n<\/ul>\n<p><\/p>\n<h1 id=\"specifika-ispolzovaniya\">Usage specifics<\/h1>\n<p><\/p>\n<p>Let\u2019s take a look at the tasks we historically solved with Redis and what functionality we used:<\/p>\n<p><\/p>\n<ul>\n<li>Cache before requests to remote services such as 2GIS | Golang<br \/>\n<blockquote><p>GET SET MGET MSET \"SELECT DB\"\n<\/p><\/blockquote>\n<\/li>\n<li>Cache before MYSQL | PHP<br \/>\n<blockquote><p>GET SET MGET MSET SCAN \"KEY BY PATTERN\" \"SELECT DB\"\n<\/p><\/blockquote>\n<\/li>\n<li>Main storage for the session handling service and driver coordinates | Golang<br \/>\n<blockquote><p>GET SET MGET MSET \"SELECT DB\" \"ADD GEO KEY\" \"GET GEO KEY\" SCAN\n<\/p><\/blockquote>\n<\/li>\n<\/ul>\n<p><\/p>\n<p>As you can see, there\u2019s no advanced mathematics involved. So what\u2019s the complexity? Let\u2019s analyze each method separately.<\/p>\n<p><\/p>\n<p>Element.getAnimations()<br \/>\nDescription<br \/>\nRedis-cluster features<br \/>\nSolution<\/p>\n<p>GET SET<br \/>\nWrite\/read a key<\/p>\n<p>MGET MSET<br \/>\nWrite\/read multiple keys<br \/>\nKeys will be distributed across different nodes. Ready-made libraries can only perform Multi-operations within a single node<br \/>\nReplace MGET with a pipeline of N GET operations<\/p>\n<p>SELECT DB<br \/>\nSelect the database we will work with<br \/>\nDoes not support multiple databases<br \/>\nStore everything in one database. Add prefixes to keys<\/p>\n<p>SCAN<br \/>\nIterate through all keys in the database<br \/>\nSince we have only one database, iterating through all keys in the cluster is too costly<br \/>\nMaintain an invariant within a single key and perform HSCAN on that key. Or eliminate it entirely<\/p>\n<p>GEO<br \/>\nOperations with geo-key<br \/>\nGeo-key is not sharded<\/p>\n<p>KEY BY PATTERN<br \/>\nSearch for a key by pattern<br \/>\nSince we have only one database, we will search through all keys in the cluster. This is too costly<br \/>\nEliminate or maintain the invariant, as with SCAN<\/p>\n<p><\/p>\n<h1 id=\"redis-vs-redis-cluster\">Redis vs Redis-cluster<\/h1>\n<p><\/p>\n<p>What do we lose and gain when switching to a cluster?<\/p>\n<p><\/p>\n<ul>\n<li>Disadvantages: we lose the functionality of multiple databases. \n<ul>\n<li>If we want to store logically unrelated data in one cluster, we\u2019ll have to use workarounds like prefixes. <\/li>\n<li>We lose all \u2018database-wide\u2019 operations such as SCAN, DBSIZE, CLEAR DB, etc.<\/li>\n<li>Multi-operations have become significantly more complex to implement, as it may require accessing multiple nodes.<\/li>\n<\/ul>\n<\/li>\n<li>Advantages: \n<ul>\n<li>Fault tolerance in the form of failover master switching.<\/li>\n<li>Sharding on the Redis side.<\/li>\n<li>Atomic transfer of data between nodes without downtime.<\/li>\n<li>Adding and reallocating resources and loads without downtime.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<p><\/p>\n<p><em>I would conclude that if you don't need to ensure a high level of fault tolerance, then migrating to a cluster is not worth it, as it can be a non-trivial task. However, if you're choosing between a standalone version and a clustered one from the start, you should opt for the cluster, as it is no worse and will relieve you of some headaches.<\/em><\/p>\n<p><\/p>\n<h1 id=\"podgotovka-k-pereezdu\">Preparation for Migration<\/h1>\n<p><\/p>\n<p>Let\u2019s start with the migration requirements:<\/p>\n<p><\/p>\n<ul>\n<li>It must be seamless. A complete service outage for 5 minutes is unacceptable.<\/li>\n<li>It has to be as safe and gradual as possible. We want to have some control over the situation. We don\u2019t want to dump everything at once and pray over the rollback button.<\/li>\n<li>Minimal data loss during migration. We understand that migrating atomically will be very difficult, so we allow for some desynchronization between the data in the regular and clustered Redis.<\/li>\n<\/ul>\n<p><\/p>\n<h1 id=\"obsluzhivanie-klastera\">Cluster Maintenance<\/h1>\n<p><\/p>\n<p>Right before the migration, we should consider whether we can maintain the cluster:<\/p>\n<p><\/p>\n<ul>\n<li>Monitoring. We use Prometheus and Grafana to track CPU load, memory usage, number of clients, number of GET, SET, AUTH operations, etc.<\/li>\n<li>Expertise. Imagine that tomorrow you'll be responsible for a huge cluster. If it breaks down, no one but you can fix it. If it starts to lag, everyone will come to you. If resources need to be added or load needs to be redistributed, again, they will come to you. To avoid going gray at 25, it's essential to anticipate these scenarios and test in advance how the technology will behave during various actions. We'll discuss this in more detail in the 'Expertise' section.<\/li>\n<li>Monitoring and Alerts. When a cluster breaks down, you want to be the first to know. Here we have limited ourselves to alerts indicating that all nodes are returning the same status information about the cluster (yes, it can be different sometimes). Other issues can be noticed quicker through the alerts of Redis client services.<\/li>\n<\/ul>\n<p><\/p>\n<h1 id=\"pereezd\">Migration<\/h1>\n<p><\/p>\n<p>How we will migrate:<\/p>\n<p><\/p>\n<ul>\n<li>First, it is necessary to prepare the library for working with the cluster. As a base for the Go version, we took go-redis and made some adjustments to suit our needs. We implemented Multi-methods via pipelines and slightly modified the request retry rules. The PHP version encountered more issues, but ultimately, we settled on php-redis. They recently introduced cluster support, and in our view, it looks promising.<\/li>\n<li>Next, you need to deploy the cluster itself. This is done literally in two commands based on the configuration file. We will discuss the setup in more detail below.<\/li>\n<li>For a gradual transition, we use dry-mode. Since we have two versions of the library with the same interface (one for the regular version, the other for the cluster), it is straightforward to create a wrapper that will work with the separate version while simultaneously duplicating all requests to the cluster, comparing responses, and logging discrepancies (in our case, to NewRelic). Thus, even if the cluster version breaks during deployment, our production will remain unaffected. <\/li>\n<li>By deploying the cluster in dry mode, we can calmly monitor the discrepancy graph of responses. If the error rate is slowly but surely approaching a small constant, then everything is fine. Why are there still discrepancies? Because the writing in the separate version happens slightly earlier than in the cluster, leading to possible data discrepancies due to micro-lag. We just need to check the discrepancy logs, and if all of them can be explained by the non-atomic nature of the writing, we can proceed.<\/li>\n<li>Now we can switch dry-mode back. We will write and read from the cluster while duplicating to the separate version. Why? Over the next week, we want to observe the cluster's performance. If it turns out that there are issues under peak load, or if we overlooked something, we always have a fallback to the old code and current data thanks to dry-mode.<\/li>\n<li>Finally, we need to disable dry-mode and dismantle the separate version. <\/li>\n<\/ul>\n<p><\/p>\n<h1 id=\"ekspertiza\">Expertise<\/h1>\n<p><\/p>\n<p>First, a brief overview of the structure of the cluster.<\/p>\n<p><\/p>\n<p>First and foremost, Redis is a key-value store. Arbitrary strings are used as keys. Numbers, strings, and entire structures can be used as values. There are a vast number of these structures, but for understanding the overall design, this is not important.<br \/>\nThe next level of abstraction after keys is slots (SLOTS). Each key belongs to one of 16,383 slots. Each slot can contain any number of keys. Thus, all keys are divided into 16,383 non-overlapping sets.<br \/>\n<img decoding=\"async\" alt=\"On the transition from Redis to Redis-cluster\" src=\"\/wp-content\/uploads\/2020\/08\/a5e4be23381b42287f693e01d5d59a99.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Next, there must be N master nodes in the cluster. Each node can be thought of as a separate Redis instance that knows everything about the other nodes within the cluster. Each master node contains a certain number of slots. Each slot belongs to only one master node. All slots need to be distributed among the nodes. If some slots remain unallocated, the keys stored in them will be inaccessible. It makes sense to run each master node on a separate logical or physical machine. It's also important to remember that each node operates on a single core, and if you want to run multiple Redis instances on one logical machine, ensure that they operate on different cores (we haven't tried this, but in theory, it should work). Essentially, master nodes provide standard sharding, and a greater number of master nodes allows for scaling write and read requests.<\/p>\n<p><\/p>\n<p>After all keys are distributed among the slots, and the slots are spread across the master nodes, an arbitrary number of slave nodes can be added to each master node. Inside each such 'master-slave' pairing, standard replication will occur. Slaves are necessary for scaling read requests and for failover in case the master fails.<br \/>\n<img decoding=\"async\" alt=\"On the transition from Redis to Redis-cluster\" src=\"\/wp-content\/uploads\/2020\/08\/90feb7ef9dacb858d5f21edc214df14d.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Now let's discuss the operations that we should know how to perform.<\/p>\n<p><\/p>\n<p>We will access the system through Redis-CLI. Since Redis does not have a single entry point, the following operations can be performed on any of the nodes. In each point, I specifically note the ability to perform the operation under load.<\/p>\n<p><\/p>\n<ul>\n<li>The first and most important operation we will need is: cluster nodes. It returns the state of the cluster, shows the list of nodes, their roles, the distribution of slots, etc. Additional information can be obtained with cluster info and cluster slots.<\/li>\n<li>It would be good to be able to add and remove nodes. For this, there are the cluster meet and cluster forget operations. Note that cluster forget must be applied to EACH node, both masters and replicas. The cluster meet can suffice by being called only on one node. This distinction can be confusing, so it's better to understand it before you put the cluster into production. Adding a node is safely carried out in situ and does not affect the operation of the cluster (which makes sense). However, if you plan to remove a node from the cluster, you need to ensure that there are no slots left on it (otherwise, you risk losing access to all keys on this node). Also, do not remove a master that has slaves, or else unnecessary voting will take place for a new master. If there are already no slots on the nodes, it is a minor issue, but why complicate things if you can first remove the slaves.<\/li>\n<li>If you need to forcibly swap the master and slave, the cluster failover command will be suitable. When invoking it in situ, you need to understand that during the operation, the master will be unavailable. Usually, the switch happens in less than a second, but it is not atomic. You can expect that some requests to the master during this time will complete with an error.<\/li>\n<li>Before removing a node from the cluster, there should be no slots left on it. It's better to redistribute them using the command cluster reshard. The slots will be transferred from one master to another. The entire operation may take several minutes, depending on the amount of data being transferred; however, the transfer process is safe and does not affect the operation of the cluster. Thus, all data can be transferred from one node to another under load, without worrying about their availability. However, there are nuances. First, the transfer of data is associated with a certain load on both the sending and receiving nodes. If the receiving node is already heavily loaded in terms of CPU, it\u2019s advisable not to further burden it with incoming data. Secondly, as soon as no slots remain on the sending master, all its slaves will immediately switch to the master to which these slots have been transferred. The problem is that all these slaves will want to synchronize data at once. You will be fortunate if it\u2019s a partial synchronization and not a full one. Keep this in mind, and combine the operations of slot transfer and slave disconnection\/transference. Or hope that you have enough margin for safety.<\/li>\n<li>What to do if you find that slots have been lost during the transfer? I hope this issue does not affect you, but if it does, there is the operation cluster fix. It will randomly distribute the slots across nodes to some extent. I recommend checking its operation by first removing the node with the distributed slots from the cluster. Since the data in the undistributed slots is already inaccessible, it\u2019s too late to worry about availability issues with these slots. In turn, the operation will not affect the distributed slots.<\/li>\n<li>Another useful operation is monitor. It allows you to see in real-time the entire list of requests going to the node. Moreover, you can use grep with it to check if the required traffic is present.<\/li>\n<\/ul>\n<p><\/p>\n<p>It is also worth mentioning the master failover procedure. In brief, it exists, and in my opinion, it works brilliantly. However, don't think that if you pull the plug on the machine with the master node, Redis will instantly switch over and clients won't notice any downtime. In my experience, the switch occurs in a few seconds. During this time, some data will be unavailable: the master\u2019s unavailability is detected, nodes vote for a new one, slaves switch over, and data gets synchronized. The best way to ensure the scheme works is to conduct local drills. Spin up a cluster on your laptop, apply minimal load, simulate a failure (for example, by blocking ports), and assess the switch-over speed. In my opinion, only by playing around this way for a day or two can you be confident in the technology's functionality. Well, or hope that the software used by half of the internet surely works.<\/p>\n<p><\/p>\n<h1 id=\"konfiguraciya\">Configuration<\/h1>\n<p><\/p>\n<p>Often, configuration is the first thing you need to get started with a tool. Once everything is up and running, you don\u2019t want to touch the config. It takes a certain effort to force yourself to revisit the settings and thoroughly comb through them. In my memory, we had at least two serious blunders due to negligence concerning configuration. Pay special attention to the following points:<\/p>\n<p><\/p>\n<ul>\n<li>timeout 0<br \/>\n<em>The time after which inactive connections are closed (in seconds). 0 means they do not close.<\/em><br \/>\nNot every one of our libraries was capable of properly closing connections. Disabling this setting risks hitting the limit on the number of clients. On the other hand, if such an issue exists, automatic disconnection of lost connections will mask it, and we may not notice it. Furthermore, this setting should not be enabled when using persistent connections.<\/li>\n<li>Save x y &amp; appendonly yes<br \/>\n<em>Saving RDB snapshots.<\/em><br \/>\nWe will discuss RDB\/AOF issues in detail below.<\/li>\n<li>stop-writes-on-bgsave-error no &amp; slave-serve-stale-data yes<br \/>\n<em>If enabled, when the RDB snapshot fails, the master will stop accepting modification requests. If the connection to the master is lost, the slave can continue to respond to requests (yes). Or it can stop responding (no).<\/em><br \/>\nWe are not satisfied with a situation where Redis turns into a pumpkin.<\/li>\n<li>repl-ping-slave-period 5<br \/>\n<em>After this period, we will start to worry that the master has failed and it\u2019s time to perform a failover.<\/em><br \/>\nWe will have to manually find a balance between false positives and triggering a failover. In our experience, this is about 5 seconds.<\/li>\n<li>repl-backlog-size 1024mb &amp; epl-backlog-ttl 0<br \/>\n<em>This is the amount of data we can store in the buffer for a disconnected replica. If the buffer runs out, we will have to fully synchronize.<\/em><br \/>\nExperience suggests that it\u2019s better to set a higher value. There are plenty of reasons why a replica might start lagging. If it does lag, it\u2019s likely that your master is already struggling, and full synchronization will be the last straw.<\/li>\n<li>maxclients 10000<br \/>\n<em>The maximum number of simultaneous clients.<\/em><br \/>\nIn our experience, it\u2019s better to set a higher value. Redis handles 10,000 connections well. Just make sure the system has enough sockets. <\/li>\n<li>maxmemory-policy volatile-ttl<br \/>\n<em>The rule by which keys are deleted when the memory limit is reached.<\/em><br \/>\nWhat\u2019s important here isn\u2019t the rule itself but the understanding of how this will happen. Redis deserves praise for its ability to operate smoothly when reaching memory limits. <\/li>\n<\/ul>\n<p><\/p>\n<h1 id=\"problemy-rdb-i-aof\">RDB and AOF issues<\/h1>\n<p><\/p>\n<p>Although Redis stores all information in memory, there is also a mechanism for saving data to disk. More specifically, there are three mechanisms:<\/p>\n<p><\/p>\n<ul>\n<li>RDB snapshot \u2014 a complete snapshot of all data. It\u2019s configured using SAVE X Y and reads as 'Save a complete snapshot of all data every X seconds if at least Y keys have changed.'<\/li>\n<li>Append-only file \u2014 a list of operations in the order they were executed. It adds newly received operations to the file every X seconds or every Y operations.<\/li>\n<li>RDB and AOF \u2014 a combination of the two previous methods.<\/li>\n<\/ul>\n<p><\/p>\n<p>Each method has its advantages and disadvantages; I won\u2019t list them all, but I will highlight a few less obvious points, in my opinion.<\/p>\n<p><\/p>\n<p>Firstly, saving an RDB snapshot requires calling FORK. If there\u2019s a lot of data, this can hang Redis for a period ranging from a few milliseconds to a second. Additionally, the system needs to allocate memory for that snapshot, which leads to the necessity of having double the RAM on the logical machine: if 8 GB is allocated to Redis, there must be 16 GB available on the virtual machine.<\/p>\n<p><\/p>\n<p>Secondly, there are issues with partial synchronization. In AOF mode, a full synchronization may occur instead of partial during the re-connection of the slave. I couldn't figure out why this happens, but it's worth remembering.<\/p>\n<p><\/p>\n<p>These two points already make us think about whether we really need this data on disk when it is duplicated by the slaves anyway. Data loss can only occur if all slaves fail, which is a 'data center fire' level problem. As a compromise, one might suggest keeping data only on slaves, but in that case, we need to ensure that these slaves never become masters during a failover (there is a priority setting for slaves in their configuration to achieve this). In each specific case, we consider whether to save data to disk, and most often we respond with 'no.'<\/p>\n<p><\/p>\n<h1 id=\"zaklyuchenie\">Conclusion<\/h1>\n<p><\/p>\n<p>In conclusion, I hope I have provided a general overview of how redis-cluster works for those who have never heard of it, and highlighted some non-obvious aspects for those who have been using it for a while.<br \/>\nThank you for your time, and as always, comments on the topic are welcome.<\/p>\n<p>Source: <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\/en\/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=\"en_US\" \/>\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\/en\/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\udd47On migrating from Redis to Redis-cluster | ProHoster","description":"Coming to a product that is evolving more.","canonical_url":"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/o-pereezde-s-redis-na-redis-cluster","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"en_US","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\/en\/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\/en\/wp-json\/wp\/v2\/posts\/91846","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/comments?post=91846"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/posts\/91846\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/media\/91847"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/media?parent=91846"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/categories?post=91846"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/tags?post=91846"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}