{"id":73446,"date":"2020-03-09T20:41:59","date_gmt":"2020-03-09T17:41:59","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/pochemu-mozhet-ponadobitsya-polusinhronnaya-replikacziya"},"modified":"2020-03-09T20:41:59","modified_gmt":"2020-03-09T17:41:59","slug":"pochemu-mozhet-ponadobitsya-polusinhronnaya-replikacziya","status":"publish","type":"post","link":"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/pochemu-mozhet-ponadobitsya-polusinhronnaya-replikacziya","title":{"rendered":"Why might semi-synchronous replication be necessary?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><i>Hello everyone. This is Vladislav Rodin. Currently, I am teaching courses on software architecture and high-load software architecture on the OTUS portal. <b>With the start of a new stream of the course approaching, <noindex><a rel=\"nofollow\" href=\"https:\/\/otus.pw\/jvDY\/\">\u00abHigh Load Architect\u00bb<\/a><\/noindex> I decided to write a small original article that I want to share with you.<\/b><\/i><\/p>\n<p><img decoding=\"async\" alt=\"Why might semi-synchronous replication be necessary?\" src=\"\/wp-content\/uploads\/2020\/03\/c2a1ea514249f8fca1ab9f668a899981.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>Introduction<\/h2>\n<p>\nDue to the fact that an HDD can perform only about 400-700 operations per second (which is incomparable to the typical RPS for a high-load system), a traditional disk database represents a bottleneck in the architecture. Therefore, it is essential to pay special attention to the scaling patterns of this storage.<\/p>\n<p>Currently, there are 2 scaling patterns for the database: replication and sharding. Sharding allows for scaling the write operation and, consequently, reducing the rps for writes allocated to a single server of your cluster. Replication allows doing the same, but with read operations. This article is dedicated to this pattern.<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h2>Replication<\/h2>\n<p>\nIf we look at replication from a very high level, it\u2019s a simple thing: you had one server where the data was stored, and then this server couldn't handle the read load of this data. You add a couple of servers, synchronize the data across all servers, and the user can read from any server in your cluster. <\/p>\n<p>Despite the apparent simplicity, there are several ways to classify various implementations of this scheme:<\/p>\n<ul>\n<li>By roles in the cluster (master-master or master-slave)<\/li>\n<li>By the objects being transmitted (row-based, statement-based, or mixed)<\/li>\n<li>By the mechanism of synchronizing nodes<\/li>\n<\/ul>\n<p>\nToday we will focus specifically on the third point. <\/p>\n<h2>How the transaction commit occurs<\/h2>\n<p>\nThis topic is not directly related to replication, and a separate article could be written on it; however, since further reading would be pointless without understanding the transaction commit mechanism, I will remind you of the most basic things. The transaction commit occurs in 3 stages:<\/p>\n<ol>\n<li>Recording the transaction in the database log.<\/li>\n<li>Applying the transaction in the database engine.<\/li>\n<li>Returning confirmation to the client of the successful application of the transaction.<\/li>\n<\/ol>\n<p>\nIn various databases, this algorithm may have nuances: for example, the InnoDB engine of MySQL has two logs: one for replication (binary log) and another for maintaining ACID (undo\/redo log), while PostgreSQL has one log that performs both functions (write-ahead log = WAL). However, the general concept presented above allows such nuances to be disregarded.<\/p>\n<h2>Synchronous (sync) replication<\/h2>\n<p>\nLet's add logic for replicating the changes received to the transaction commit algorithm:<\/p>\n<ol>\n<li>Recording the transaction in the database log.<\/li>\n<li>Applying the transaction in the database engine.<\/li>\n<li><b>Sending data to all replicas.<\/b><\/li>\n<li><b>Receiving confirmation from all replicas that the transaction has been executed on them.<\/b><\/li>\n<li>Returning confirmation to the client of the successful application of the transaction.<\/li>\n<\/ol>\n<p>\nWith this approach, we encounter a number of drawbacks: <\/p>\n<ul>\n<li>the client waits for changes to be applied on all replicas.<\/li>\n<li>as the number of nodes in the cluster increases, we reduce the likelihood that the write operation will succeed.<\/li>\n<\/ul>\n<p>\nIf the first point is relatively clear, the reasons for the second point need clarification. If we do not receive a response from at least one node during synchronous replication, we roll back the transaction. Therefore, by increasing the number of nodes in the cluster, you increase the likelihood that the write operation will fail. <\/p>\n<p>Can we wait for confirmation from only a portion of the nodes, for example, 51% (quorum)? Yes, we can, but in the classic version, confirmation is required from all nodes, as this is how we ensure full data consistency in the cluster, which is undoubtedly an advantage of this type of replication.<\/p>\n<h2>Asynchronous (async) replication<\/h2>\n<p>\nLet's modify the previous algorithm. We will send data to the replicas \"sometime later,\" and \"sometime later\" the changes will be applied on the replicas:<\/p>\n<ol>\n<li>Recording the transaction in the database log.<\/li>\n<li>Applying the transaction in the database engine.<\/li>\n<li>Returning confirmation to the client of the successful application of the transaction.<\/li>\n<li><b>Sending data to replicas and applying changes by them.<\/b><\/li>\n<\/ol>\n<p>\nThis approach results in the cluster operating quickly, as we do not keep the client waiting while the data reaches the replicas and gets committed.<\/p>\n<p>However, the condition of sending data to the replicas \"sometime later\" can lead to transaction loss, specifically the loss of a confirmed transaction to the user, as if the data has not been replicated in time, while the confirmation of successful operation is sent to the client, and there's a failure of the HDD on the node that received the changes, we lose that transaction, which can lead to very unpleasant consequences.<\/p>\n<h2>Semisynchronous (semisync) replication<\/h2>\n<p>\nFinally, we have reached semi-synchronous replication. This type of replication is not very well-known or common, but it is quite interesting as it can combine the advantages of both synchronous and asynchronous replication.<\/p>\n<p>Let\u2019s try to merge the two previous approaches. We won't keep the client waiting for long, but we will require that the data is replicated:<\/p>\n<ol>\n<li>Recording the transaction in the database log.<\/li>\n<li>Applying the transaction in the database engine.<\/li>\n<li><b>Sending data to replicas.<\/b><\/li>\n<li><b>Receiving confirmation from a replica about the receipt of changes (they will be applied \"sometime later\").<\/b><\/li>\n<li>Returning confirmation to the client of the successful application of the transaction.<\/li>\n<\/ol>\n<p>\nNote that with this algorithm, a transaction loss occurs only if both the node receiving the changes and the replica node crash. The likelihood of such a failure is considered low, and these risks are accepted. <\/p>\n<p>However, this approach has a risk of phantom reads. Imagine the following scenario: at step 4, we did not receive confirmation from any replica. We must roll back this transaction and not return confirmation to the client. Since the data was applied at step 2, there is a time gap between the end of step 2 and the rollback of the transaction, during which parallel transactions may see changes that should not exist in the database. <\/p>\n<h2>Lose-less semi-sync replication<\/h2>\n<p>\nIf we think a bit, we can simply switch the steps of the algorithm to resolve the phantom read issue in this scenario:<\/p>\n<ol>\n<li>Recording the transaction in the database log.<\/li>\n<li><b>Sending data to the replica.<\/b><\/li>\n<li><b>Receiving confirmation from a replica about the receipt of changes (they will be applied \"sometime later\").<\/b><\/li>\n<li>Applying the transaction in the database engine.<\/li>\n<li>Returning confirmation to the client of the successful application of the transaction.<\/li>\n<\/ol>\n<p>\nNow we commit changes only if they have been replicated. <\/p>\n<h2>Output<\/h2>\n<p>\nAs always, there are no perfect solutions; there are sets of solutions, each with its advantages and disadvantages, suitable for solving different classes of tasks. This is also true for choosing a synchronization mechanism for a replicated database. The set of advantages that semi-synchronous replication has is quite solid and interesting enough to be considered noteworthy, despite its low prevalence.<\/p>\n<p><b>That\u2019s all. See you at the <noindex><a rel=\"nofollow\" href=\"https:\/\/otus.pw\/jvDY\/\">course<\/a><\/noindex>!<\/b><br \/>\n<br \/>Source: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/otus\/blog\/491106\/\">habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u0412\u0441\u0435\u043c \u043f\u0440\u0438\u0432\u0435\u0442. \u041d\u0430 \u0441\u0432\u044f\u0437\u0438 \u0412\u043b\u0430\u0434\u0438\u0441\u043b\u0430\u0432 \u0420\u043e\u0434\u0438\u043d. \u0412 \u043d\u0430\u0441\u0442\u043e\u044f\u0449\u0435\u0435 \u0432\u0440\u0435\u043c\u044f \u044f \u043f\u0440\u0435\u043f\u043e\u0434\u0430\u044e \u043d\u0430 \u043f\u043e\u0440\u0442\u0430\u043b\u0435 OTUS \u043a\u0443\u0440\u0441\u044b, \u043f\u043e\u0441\u0432\u044f\u0449\u0435\u043d\u043d\u044b\u0435 \u0430\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u0443\u0440\u0435 \u041f\u041e \u0438 \u0430\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u0443\u0440\u0435 \u041f\u041e, \u043f\u043e\u0434\u0432\u0435\u0440\u0436\u0435\u043d\u043d\u043e\u0433\u043e \u0432\u044b\u0441\u043e\u043a\u043e\u0439 \u043d\u0430\u0433\u0440\u0443\u0437\u043a\u0435. \u0412 \u043f\u0440\u0435\u0434\u0434\u0432\u0435\u0440\u0438\u0438 \u0441\u0442\u0430\u0440\u0442\u0430 \u043d\u043e\u0432\u043e\u0433\u043e \u043f\u043e\u0442\u043e\u043a\u0430 \u043a\u0443\u0440\u0441\u0430 \u00ab\u0410\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u043e\u0440 \u0432\u044b\u0441\u043e\u043a\u0438\u0445 \u043d\u0430\u0433\u0440\u0443\u0437\u043e\u043a\u00bb \u044f \u0440\u0435\u0448\u0438\u043b \u043d\u0430\u043f\u0438\u0441\u0430\u0442\u044c \u043d\u0435\u0431\u043e\u043b\u044c\u0448\u043e\u0439 \u0430\u0432\u0442\u043e\u0440\u0441\u043a\u0438\u0439 \u043c\u0430\u0442\u0435\u0440\u0438\u0430\u043b, \u043a\u043e\u0442\u043e\u0440\u044b\u043c \u0445\u043e\u0447\u0443 \u043f\u043e\u0434\u0435\u043b\u0438\u0442\u044c\u0441\u044f \u0441 \u0432\u0430\u043c\u0438. \u0412\u0432\u0435\u0434\u0435\u043d\u0438\u0435 \u0418\u0437-\u0437\u0430 \u0442\u043e\u0433\u043e, \u0447\u0442\u043e \u043d\u0430 HDD \u043c\u043e\u0436\u0435\u0442 \u0432\u044b\u043f\u043e\u043b\u043d\u044f\u0442\u044c\u0441\u044f \u043b\u0438\u0448\u044c \u043f\u043e\u0440\u044f\u0434\u043a\u0430 400-700 [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":73447,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-73446","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=\"\u0412\u0441\u0435\u043c \u043f\u0440\u0438\u0432\u0435\u0442. \u041d\u0430 \u0441\u0432\u044f\u0437\u0438 \u0412\u043b\u0430\u0434\u0438\u0441\u043b\u0430\u0432 \u0420\u043e\u0434\u0438\u043d. \u0412 \u043d\u0430\u0441\u0442\u043e\u044f\u0449\u0435\u0435 \u0432\u0440\u0435\u043c\u044f \u044f \u043f\u0440\u0435\u043f\u043e\u0434\u0430\u044e \u043d\u0430 \u043f\u043e\u0440\u0442\u0430\u043b\u0435 OTUS \u043a\u0443\u0440\u0441\u044b, \u043f\u043e\u0441\u0432\u044f\u0449\u0435\u043d\u043d\u044b\u0435 \u0430\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u0443\u0440\u0435 \u041f\u041e \u0438 \u0430\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u0443\u0440\u0435 \u041f\u041e, \u043f\u043e\u0434\u0432\u0435\u0440\u0436\u0435\u043d\u043d\u043e\u0433\u043e \u0432\u044b\u0441\u043e\u043a\u043e\u0439 \u043d\u0430\u0433\u0440\u0443\u0437\u043a\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\/pochemu-mozhet-ponadobitsya-polusinhronnaya-replikacziya\" \/>\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\u041f\u043e\u0447\u0435\u043c\u0443 \u043c\u043e\u0436\u0435\u0442 \u043f\u043e\u043d\u0430\u0434\u043e\u0431\u0438\u0442\u044c\u0441\u044f \u043f\u043e\u043b\u0443\u0441\u0438\u043d\u0445\u0440\u043e\u043d\u043d\u0430\u044f \u0440\u0435\u043f\u043b\u0438\u043a\u0430\u0446\u0438\u044f? | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u0412\u0441\u0435\u043c \u043f\u0440\u0438\u0432\u0435\u0442. \u041d\u0430 \u0441\u0432\u044f\u0437\u0438 \u0412\u043b\u0430\u0434\u0438\u0441\u043b\u0430\u0432 \u0420\u043e\u0434\u0438\u043d. \u0412 \u043d\u0430\u0441\u0442\u043e\u044f\u0449\u0435\u0435 \u0432\u0440\u0435\u043c\u044f \u044f \u043f\u0440\u0435\u043f\u043e\u0434\u0430\u044e \u043d\u0430 \u043f\u043e\u0440\u0442\u0430\u043b\u0435 OTUS \u043a\u0443\u0440\u0441\u044b, \u043f\u043e\u0441\u0432\u044f\u0449\u0435\u043d\u043d\u044b\u0435 \u0430\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u0443\u0440\u0435 \u041f\u041e \u0438 \u0430\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u0443\u0440\u0435 \u041f\u041e, \u043f\u043e\u0434\u0432\u0435\u0440\u0436\u0435\u043d\u043d\u043e\u0433\u043e \u0432\u044b\u0441\u043e\u043a\u043e\u0439 \u043d\u0430\u0433\u0440\u0443\u0437\u043a\u0435.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/pochemu-mozhet-ponadobitsya-polusinhronnaya-replikacziya\" \/>\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-03-09T17:41:59+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-03-09T17:41:59+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\udd47Why might semi-synchronous replication be needed? | ProHoster","description":"Hello everyone. This is Vladislav Rodin. Currently, I am teaching courses on software architecture and high-load software architecture on the OTUS portal.","canonical_url":"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/pochemu-mozhet-ponadobitsya-polusinhronnaya-replikacziya","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\u041f\u043e\u0447\u0435\u043c\u0443 \u043c\u043e\u0436\u0435\u0442 \u043f\u043e\u043d\u0430\u0434\u043e\u0431\u0438\u0442\u044c\u0441\u044f \u043f\u043e\u043b\u0443\u0441\u0438\u043d\u0445\u0440\u043e\u043d\u043d\u0430\u044f \u0440\u0435\u043f\u043b\u0438\u043a\u0430\u0446\u0438\u044f? | ProHoster","og:description":"\u0412\u0441\u0435\u043c \u043f\u0440\u0438\u0432\u0435\u0442. \u041d\u0430 \u0441\u0432\u044f\u0437\u0438 \u0412\u043b\u0430\u0434\u0438\u0441\u043b\u0430\u0432 \u0420\u043e\u0434\u0438\u043d. \u0412 \u043d\u0430\u0441\u0442\u043e\u044f\u0449\u0435\u0435 \u0432\u0440\u0435\u043c\u044f \u044f \u043f\u0440\u0435\u043f\u043e\u0434\u0430\u044e \u043d\u0430 \u043f\u043e\u0440\u0442\u0430\u043b\u0435 OTUS \u043a\u0443\u0440\u0441\u044b, \u043f\u043e\u0441\u0432\u044f\u0449\u0435\u043d\u043d\u044b\u0435 \u0430\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u0443\u0440\u0435 \u041f\u041e \u0438 \u0430\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u0443\u0440\u0435 \u041f\u041e, \u043f\u043e\u0434\u0432\u0435\u0440\u0436\u0435\u043d\u043d\u043e\u0433\u043e \u0432\u044b\u0441\u043e\u043a\u043e\u0439 \u043d\u0430\u0433\u0440\u0443\u0437\u043a\u0435.","og:url":"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/pochemu-mozhet-ponadobitsya-polusinhronnaya-replikacziya","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-03-09T17:41:59+00:00","article:modified_time":"2020-03-09T17:41:59+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"73446","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 11:50:08","updated":"2022-09-28 11:57:57","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\/73446","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=73446"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/posts\/73446\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/media\/73447"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/media?parent=73446"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/categories?post=73446"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/tags?post=73446"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}