{"id":1131,"date":"2016-03-24T10:13:34","date_gmt":"2016-03-24T13:13:34","guid":{"rendered":"http:\/\/wagnerbianchi.com\/blog\/?p=1131"},"modified":"2016-03-25T19:26:09","modified_gmt":"2016-03-25T22:26:09","slug":"mariadb-10-1-msr-and-mts","status":"publish","type":"post","link":"http:\/\/wagnerbianchi.com\/blog\/?p=1131","title":{"rendered":"MariaDB 10.1, MSR and MTS"},"content":{"rendered":"

As a preparation of my presentation together with Max Bubenick<\/a> at 2016’s Percona Live, happening in Santa Clara, CA, US, I’m running as many tests as I can to check all the maturity of the technology of feature we are about to talking about.\u00a0This is a common sense that you need to go over the planned to be presented feature in order to address some of the implicit subjects. This way, we stared discussing about a crash on MariaDB 10.1 setup for a Multi-Source Replication Slave, being this slave server a Multi-Threaded Slave as well running with 12 threads dedicated to execute raw updates from the relay log, having at least 3 out of those 12 threads dedicated to each of the exiting domain_id. You can check the numbers of threads dedicated to each domain_id interpreting the contents of mysql.gtid_slave_pos table to keep track of their current position (the global transaction ID of the last transaction applied). Using the table allows the slave to maintain a consistent value for the gtid_slave_pos system variable across server restarts. That is, as a I have setup 3 masters and one multi-source slave, in this scenario I’ve got domains #2, #3, #4, being the multi-source slave the domain #1. That justifies the 12 threads and at least 3 for each domain.<\/p>\n

Below, the designed architecture:<\/p>\n

\"Screen<\/a><\/p>\n

box01 - @@server_id=1, @@gtid_domain_id=1\r\nbox02 - @@server_id=2, @@gtid_domain_id=2\r\nbox03 - @@server_id=3, @@gtid_domain_id=3\r\nbox04 - @@server_id=4, @@gtid_domain_id=4<\/pre>\n
After configuring the multi-source replication and having configuration files well set, I started some tests.<\/p>\n
#: Connection name with box02\r\nMariaDB [(none)]> change master 'box02' to master_host='192.168.0.102', master_user='repl', master_password='Bi@nchI', master_use_gtid=current_pos;\r\n#: Connection name with box03\r\nMariaDB [(none)]> change master 'box03' to master_host='192.168.0.102', master_user='repl', master_password='Bi@nchI', master_use_gtid=current_pos;\r\n#: Connection name with box04\r\nMariaDB [(none)]> change master 'box04' to master_host='192.168.0.104', master_user='repl', master_password='Bi@nchI', master_use_gtid=current_pos;<\/pre>\n
Just to make sure we’re on the same page, I created on the master’s side individual databases to make the masters to write just to their own database schema to avoid conflicts on writing to the same table (that’s an existing successful case I have to formulate a new blog to tell<\/em>). So, after that, I used sysbench to prepare the test case, creating\u00a010 tables in each database schema with 10000 rows each table. Finally, I run sysbench with the following structure to execute a simple 60 secs test using OLTP script:<\/p>\n
[vagrant@maria0X ~]$ sudo sysbench --test=\/usr\/share\/doc\/sysbench\/tests\/db\/oltp.lua --oltp-table-size=10000 --mysql-db=box0X --oltp-tables-count=10 --mysql-user=root --db-driver=mysql --mysql-table-engine=innodb --max-time=60 --max-requests=0 --report-interval=60 --num-threads=50 --mysql-engine-trx=yes run<\/pre>\n
I started the above sysbench on all the three masters and then, the multi-source slave has crashed with the below error:<\/p>\n
2016-03-23 19:54:57 140604957547264 [ERROR] Slave (additional info): Commit failed due to failure of an earlier commit on which this one depends Error_code: 1964\r\n2016-03-23 19:54:57 140604957547264 [Warning] Slave: Running in read-only mode Error_code: 1836\r\n2016-03-23 19:54:57 140604957547264 [Warning] Slave: Table 'sbtest2' is read only Error_code: 1036\r\n2016-03-23 19:54:57 140604957547264 [Warning] Slave: Commit failed due to failure of an earlier commit on which this one depends Error_code: 1964\r\n2016-03-23 19:54:57 140604957547264 [Warning] Slave: Commit failed due to failure of an earlier commit on which this one depends Error_code: 1964\r\n2016-03-23 19:54:57 140604957547264 [Warning] Slave: Commit failed due to failure of an earlier commit on which this one depends Error_code: 1964\r\n[...snip...]\r\n2016-03-23 19:54:57 140604957244160 [ERROR] Slave (additional info): Commit failed due to failure of an earlier commit on which this one depends Error_code: 1964\r\n2016-03-23 19:54:57 140604957244160 [Warning] Slave: Running in read-only mode Error_code: 1836\r\n2016-03-23 19:54:57 140604957244160 [Warning] Slave: Table 'sbtest1' is read only Error_code: 1036\r\n2016-03-23 19:54:57 140604957244160 [Warning] Slave: Commit failed due to failure of an earlier commit on which this one depends Error_code: 1964\r\n2016-03-23 19:54:57 140604957244160 [Warning] Slave: Commit failed due to failure of an earlier commit on which this one depends Error_code: 1964\r\n2016-03-23 19:54:57 140604957244160 [Warning] Slave: Commit failed due to failure of an earlier commit on which this one depends Error_code: 1964\r\n[...snip...]\r\n2016-03-23 19:59:14 140604959972096 [Note] \/usr\/sbin\/mysqld: Normal shutdown\r\n<\/pre>\n
The problem here is clear, “Commit failed due to failure of an earlier commit on which this one depends”. <\/p>\n
Furthermore, when I tried to start multi-source slave back, I found the following events added to the error log:<\/p>\n
2016-03-23 19:59:17 139987887904800 [Note] \/usr\/sbin\/mysqld (mysqld 10.1.11-MariaDB-log) starting as process 3996 ...\r\n2016-03-23 19:59:17 139987887904800 [Note] InnoDB: Using mutexes to ref count buffer pool pages\r\n2016-03-23 19:59:17 139987887904800 [Note] InnoDB: The InnoDB memory heap is disabled\r\n2016-03-23 19:59:17 139987887904800 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins\r\n2016-03-23 19:59:17 139987887904800 [Note] InnoDB: Memory barrier is not used\r\n2016-03-23 19:59:17 139987887904800 [Note] InnoDB: Compressed tables use zlib 1.2.3\r\n2016-03-23 19:59:17 139987887904800 [Note] InnoDB: Using Linux native AIO\r\n2016-03-23 19:59:17 139987887904800 [Note] InnoDB: Using generic crc32 instructions\r\n2016-03-23 19:59:17 139987887904800 [Note] InnoDB: Initializing buffer pool, size = 128.0M\r\n2016-03-23 19:59:17 139987887904800 [Note] InnoDB: Completed initialization of buffer pool\r\n2016-03-23 19:59:17 139987887904800 [Note] InnoDB: Highest supported file format is Barracuda.\r\nInnoDB: Transaction 46834 was in the XA prepared state.\r\nInnoDB: Transaction 46834 was in the XA prepared state.\r\nInnoDB: Transaction 46835 was in the XA prepared state.\r\nInnoDB: Transaction 46835 was in the XA prepared state.\r\nInnoDB: Transaction 46836 was in the XA prepared state.\r\nInnoDB: Transaction 46836 was in the XA prepared state.\r\nInnoDB: Transaction 46838 was in the XA prepared state.\r\nInnoDB: Transaction 46838 was in the XA prepared state.\r\nInnoDB: Transaction 46839 was in the XA prepared state.\r\nInnoDB: Transaction 46839 was in the XA prepared state.\r\nInnoDB: 6 transaction(s) which must be rolled back or cleaned up\r\nInnoDB: in total 4 row operations to undo\r\nInnoDB: Trx id counter is 47616\r\n2016-03-23 19:59:17 139987887904800 [Note] InnoDB: 128 rollback segment(s) are active.\r\n2016-03-23 19:59:17 139987887904800 [Note] InnoDB: Waiting for purge to start\r\nInnoDB: Starting in background the rollback of uncommitted transactions\r\n2016-03-23 19:59:17 7f51503fe700 InnoDB: Rolling back trx with id 46837, 4 rows to undo\r\n2016-03-23 19:59:17 139987215443712 [Note] InnoDB: Rollback of trx with id 46837 completed\r\n2016-03-23 19:59:17 7f51503fe700 InnoDB: Rollback of non-prepared transactions completed\r\n2016-03-23 19:59:17 139987887904800 [Note] InnoDB: Percona XtraDB (http:\/\/www.percona.com) 5.6.26-76.0 started; log sequence number 124266988\r\n2016-03-23 19:59:17 139987887904800 [Note] Plugin 'FEEDBACK' is disabled.\r\n2016-03-23 19:59:17 7f517854d820 InnoDB: Starting recovery for XA transactions...\r\n2016-03-23 19:59:17 7f517854d820 InnoDB: Transaction 46839 in prepared state after recovery\r\n2016-03-23 19:59:17 7f517854d820 InnoDB: Transaction contains changes to 7 rows\r\n2016-03-23 19:59:17 7f517854d820 InnoDB: Transaction 46838 in prepared state after recovery\r\n2016-03-23 19:59:17 7f517854d820 InnoDB: Transaction contains changes to 5 rows\r\n2016-03-23 19:59:17 7f517854d820 InnoDB: Transaction 46836 in prepared state after recovery\r\n2016-03-23 19:59:17 7f517854d820 InnoDB: Transaction contains changes to 7 rows\r\n2016-03-23 19:59:17 7f517854d820 InnoDB: Transaction 46835 in prepared state after recovery\r\n2016-03-23 19:59:17 7f517854d820 InnoDB: Transaction contains changes to 5 rows\r\n2016-03-23 19:59:17 7f517854d820 InnoDB: Transaction 46834 in prepared state after recovery\r\n2016-03-23 19:59:17 7f517854d820 InnoDB: Transaction contains changes to 7 rows\r\n2016-03-23 19:59:17 7f517854d820 InnoDB: 5 transactions in prepared state after recovery\r\n2016-03-23 19:59:17 139987887904800 [Note] Found 5 prepared transaction(s) in InnoDB\r\n2016-03-23 19:59:17 139987887904800 [ERROR] Found 5 prepared transactions! It means that mysqld was not shut down properly last time and critical recovery information (last binlog or tc.log file) was manually deleted after a crash. You have to start mysqld with --tc-heuristic-recover switch to commit or rollback pending transactions.\r\n2016-03-23 19:59:17 139987887904800 [ERROR] Aborting<\/pre>\n
So, to get the MSR Slave back:<\/p>\n
[vagrant@maria01 ~]$ sudo mysqld --defaults-file=\/etc\/my.cnf --tc-heuristic-recover=ROLLBACK\r\n2016-03-23 20:18:20 140348206848032 [Note] mysqld (mysqld 10.1.11-MariaDB-log) starting as process 4047 ...\r\n2016-03-23 20:18:21 140348206848032 [Note] InnoDB: Using mutexes to ref count buffer pool pages\r\n2016-03-23 20:18:21 140348206848032 [Note] InnoDB: The InnoDB memory heap is disabled\r\n2016-03-23 20:18:21 140348206848032 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins\r\n2016-03-23 20:18:21 140348206848032 [Note] InnoDB: Memory barrier is not used\r\n2016-03-23 20:18:21 140348206848032 [Note] InnoDB: Compressed tables use zlib 1.2.3\r\n2016-03-23 20:18:21 140348206848032 [Note] InnoDB: Using Linux native AIO\r\n2016-03-23 20:18:21 140348206848032 [Note] InnoDB: Using generic crc32 instructions\r\n2016-03-23 20:18:21 140348206848032 [Note] InnoDB: Initializing buffer pool, size = 128.0M\r\n2016-03-23 20:18:21 140348206848032 [Note] InnoDB: Completed initialization of buffer pool\r\n2016-03-23 20:18:21 140348206848032 [Note] InnoDB: Highest supported file format is Barracuda.\r\nInnoDB: Transaction 46834 was in the XA prepared state.\r\nInnoDB: Transaction 46834 was in the XA prepared state.\r\nInnoDB: Transaction 46835 was in the XA prepared state.\r\nInnoDB: Transaction 46835 was in the XA prepared state.\r\nInnoDB: Transaction 46836 was in the XA prepared state.\r\nInnoDB: Transaction 46836 was in the XA prepared state.\r\nInnoDB: Transaction 46838 was in the XA prepared state.\r\nInnoDB: Transaction 46838 was in the XA prepared state.\r\nInnoDB: Transaction 46839 was in the XA prepared state.\r\nInnoDB: Transaction 46839 was in the XA prepared state.\r\nInnoDB: 5 transaction(s) which must be rolled back or cleaned up\r\nInnoDB: in total 0 row operations to undo\r\nInnoDB: Trx id counter is 48128\r\n2016-03-23 20:18:21 140348206848032 [Note] InnoDB: 128 rollback segment(s) are active.\r\n2016-03-23 20:18:21 140348206848032 [Note] InnoDB: Waiting for purge to start\r\nInnoDB: Starting in background the rollback of uncommitted transactions\r\n2016-03-23 20:18:21 7fa534bff700 InnoDB: Rollback of non-prepared transactions completed\r\n2016-03-23 20:18:21 140348206848032 [Note] InnoDB: Percona XtraDB (http:\/\/www.percona.com) 5.6.26-76.0 started; log sequence number 124267433\r\n2016-03-23 20:18:21 140348206848032 [Note] Plugin 'FEEDBACK' is disabled.\r\n2016-03-23 20:18:21 140348206848032 [Note] Heuristic crash recovery mode\r\n2016-03-23 20:18:21 7fa55d039820 InnoDB: Starting recovery for XA transactions...\r\n2016-03-23 20:18:21 7fa55d039820 InnoDB: Transaction 46839 in prepared state after recovery\r\n2016-03-23 20:18:21 7fa55d039820 InnoDB: Transaction contains changes to 7 rows\r\n2016-03-23 20:18:21 7fa55d039820 InnoDB: Transaction 46838 in prepared state after recovery\r\n2016-03-23 20:18:21 7fa55d039820 InnoDB: Transaction contains changes to 5 rows\r\n2016-03-23 20:18:21 7fa55d039820 InnoDB: Transaction 46836 in prepared state after recovery\r\n2016-03-23 20:18:21 7fa55d039820 InnoDB: Transaction contains changes to 7 rows\r\n2016-03-23 20:18:21 7fa55d039820 InnoDB: Transaction 46835 in prepared state after recovery\r\n2016-03-23 20:18:21 7fa55d039820 InnoDB: Transaction contains changes to 5 rows\r\n2016-03-23 20:18:21 7fa55d039820 InnoDB: Transaction 46834 in prepared state after recovery\r\n2016-03-23 20:18:21 7fa55d039820 InnoDB: Transaction contains changes to 7 rows\r\n2016-03-23 20:18:21 7fa55d039820 InnoDB: 5 transactions in prepared state after recovery\r\n2016-03-23 20:18:21 140348206848032 [Note] Found 5 prepared transaction(s) in InnoDB\r\n2016-03-23 20:18:21 140347457898240 [Note] InnoDB: Dumping buffer pool(s) not yet started\r\n2016-03-23 20:18:21 140348206848032 [Note] Please restart mysqld without --tc-heuristic-recover\r\n2016-03-23 20:18:21 140348206848032 [ERROR] Can't init tc log\r\n2016-03-23 20:18:21 140348206848032 [ERROR] Aborting<\/pre>\n
And finally:<\/p>\n
[vagrant@maria01 ~]$ sudo service mysql start\r\nStarting MySQL... SUCCESS!<\/pre>\n
By the way, as per the discussion on twitter, I’m not really sure yet if this is a problem related to the in-order commit when using parallel replication which implies that a transaction commit conflict is happening at that point. Below the configuration file used for the MSR Slave, showing that it’s configured with @@slave_pararllel_mode=optimistic which as per the manual online “tries to apply most transactional DML in parallel, and handles any conflicts with rollback and retry”, more info here<\/a>.<\/p>\n
#: box01 - multi-source slave\r\n[client]\r\nport=3306\r\nsocket=\/var\/lib\/mysql\/mysql.sock\r\n[mysqld]\r\nuser=mysql\r\nport=3306\r\nsocket=\/var\/lib\/mysql\/mysql.sock\r\nbasedir=\/usr\r\ndatadir=\/var\/lib\/mysql\r\nread_only=1\r\n#: repl vars\r\nserver_id=1\r\nreport_host=box01\r\nreport_port=3306\r\nreport_user=repl\r\nlog_bin=mysql-bin\r\nlog_bin_index=mysql.index\r\nlog_slave_updates=true\r\nbinlog_format=ROW\r\n#: verify checksum on master\r\nmaster_verify_checksum=1\r\n#: gtid vars\r\ngtid_domain_id=1\r\ngtid_ignore_duplicates=ON\r\ngtid_strict_mode=1\r\n\r\n#: msr slave parallel mode *\r\nbox02.slave_parallel_mode=conservative\r\nbox03.slave_parallel_mode=conservative\r\nbox04.slave_parallel_mode=conservative\r\n\r\nslave_parallel_threads=10\r\nslave_domain_parallel_threads=2\r\nslave_parallel_max_queued=512M\r\nslave_net_timeout=15\r\nslave_sql_verify_checksum=1\r\nslave_compressed_protocol=1\r\n#: binary log group commit behavior\r\n#binlog_commit_wait_usec=100000\r\n#binlog_commit_wait_count=20<\/pre>\n
Maybe a test using @@slave_domain_parallel_threads should be done as the next step, but, if you have any additional thoughts on this, it’s really appreciated.<\/p>\n
Continuing with this, I found that Connection Names were not running in optimistic mode (it was conservative, which limits parallelism in an effort to avoid any conflicts) and then after changing that, I did the test again:<\/p>\n
#: current values\r\nMariaDB [(none)]> show all slaves status\\G\r\n              Connection_name: box02\r\n                Parallel_Mode: conservative\r\n              Connection_name: box03\r\n                Parallel_Mode: conservative\r\n              Connection_name: box04\r\n                Parallel_Mode: conservative\r\n3 rows in set (0.00 sec)\r\n\r\n#: changing Parallel Mode to Optimistic\r\nMariaDB [(none)]> stop all slaves;\r\nQuery OK, 0 rows affected, 3 warnings (0.00 sec)\r\n\r\nMariaDB [(none)]> set global box02.slave_parallel_mode='optimistic';\r\nQuery OK, 0 rows affected (0.00 sec)\r\n\r\nMariaDB [(none)]> set global box03.slave_parallel_mode='optimistic';\r\nQuery OK, 0 rows affected (0.00 sec)\r\n\r\nMariaDB [(none)]> set global box04.slave_parallel_mode='optimistic';\r\nQuery OK, 0 rows affected (0.00 sec)\r\n\r\nMariaDB [(none)]> start all slaves;\r\nQuery OK, 0 rows affected, 3 warnings (0.02 sec)\r\n\r\nMariaDB [(none)]> show all slaves status\\G\r\n              Connection_name: box02\r\n                Parallel_Mode: optimistic\r\n              Connection_name: box03\r\n                Parallel_Mode: optimistic\r\n              Connection_name: box04\r\n                Parallel_Mode: optimistic\r\n3 rows in set (0.00 sec)<\/pre>\n
The parallel threads were like:<\/p>\n
MariaDB [(none)]> SELECT ID,TIME,STATE,USER FROM INFORMATION_SCHEMA.PROCESSLIST WHERE USER='system user';\r\n+----+------+------------------------------------------------------------------+-------------+\r\n| ID | TIME | STATE                                                            | USER        |\r\n+----+------+------------------------------------------------------------------+-------------+\r\n| 46 |   81 | Slave has read all relay log; waiting for the slave I\/O thread t | system user |\r\n| 45 |   81 | Waiting for master to send event                                 | system user |\r\n| 44 |   86 | Slave has read all relay log; waiting for the slave I\/O thread t | system user |\r\n| 43 |   86 | Waiting for master to send event                                 | system user |\r\n| 42 |  102 | Slave has read all relay log; waiting for the slave I\/O thread t | system user |\r\n| 41 |  102 | Waiting for master to send event                                 | system user |\r\n| 35 |    0 | Waiting for prior transaction to commit                          | system user |\r\n| 34 |    0 | Waiting for prior transaction to commit                          | system user |\r\n| 33 |    0 | Waiting for prior transaction to commit                          | system user |\r\n| 32 |  175 | Waiting for work from SQL thread                                 | system user |\r\n| 31 |  175 | Waiting for work from SQL thread                                 | system user |\r\n| 30 |    0 | Unlocking tables                                                 | system user |\r\n| 29 |    0 | Unlocking tables                                                 | system user |\r\n| 28 |    0 | Unlocking tables                                                 | system user |\r\n| 27 |  175 | Waiting for work from SQL thread                                 | system user |\r\n| 26 |  175 | Waiting for work from SQL thread                                 | system user |\r\n+----+------+------------------------------------------------------------------+-------------+\r\n16 rows in set (0.00 sec)<\/pre>\n
Additionally, I’m curious to check now the Retried_transactions per connection Name variable to check if the retry transactions part of the optimistic parallel replication mode is really working:<\/p>\n
MariaDB [(none)]> pager egrep \"Connection|Parallel|Gtid_IO|Retried\"\r\nPAGER set to 'egrep \"Connection|Parallel|Gtid_IO|Retried\"'\r\nMariaDB [(none)]> show all slaves status\\G\r\n              Connection_name: box02\r\n                  Gtid_IO_Pos: 1-1-68,4-4-87933,3-3-77410,2-2-149378\r\n                Parallel_Mode: optimistic\r\n         Retried_transactions: 12\r\n              Connection_name: box03\r\n                  Gtid_IO_Pos: 1-1-68,4-4-87933,3-3-88622,2-2-131340\r\n                Parallel_Mode: optimistic\r\n         Retried_transactions: 3\r\n              Connection_name: box04\r\n                  Gtid_IO_Pos: 1-1-68,4-4-98365,3-3-77410,2-2-131340\r\n                Parallel_Mode: optimistic\r\n         Retried_transactions: 3\r\n3 rows in set (0.02 sec)<\/pre>\n
Additionally, we can check that the global status variable Slave_retried_transactions finnally reflects the total value to retried transactions by Connection Names on MSR Slave:<\/p>\n
MariaDB [(none)]> show global status like 'Slave_retried%';\r\n+----------------------------+-------+\r\n| Variable_name              | Value |\r\n+----------------------------+-------+\r\n| Slave_retried_transactions | 18    |\r\n+----------------------------+-------+\r\n1 row in set (0.00 sec)<\/pre>\n
So, it’s solved, slave hasn’t crashed anymore, but the question why did the MSR Slave crashed is not solved yet. But, what was learnt here was that, we can use also minimal besides of conservative for slave_parallel_mode that will play very good in this case as it’s going to only parallelizes the commit steps of transactions<\/strong>, this is the next test I would like to realize as the next step on this ever growing post. I’m going to try another post to check the relation between transaction’s conflicts rate and performance impact over the exiting slave parallel mode.<\/p>\n","protected":false},"excerpt":{"rendered":"
As a preparation of my presentation together with Max Bubenick at 2016’s Percona Live, happening in Santa Clara, CA, US, I’m running as many tests as I can to check all the maturity of the technology of feature we are about to talking about.\u00a0This is a common sense that you need to go over the […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[17,16],"tags":[],"_links":{"self":[{"href":"http:\/\/wagnerbianchi.com\/blog\/index.php?rest_route=\/wp\/v2\/posts\/1131"}],"collection":[{"href":"http:\/\/wagnerbianchi.com\/blog\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/wagnerbianchi.com\/blog\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/wagnerbianchi.com\/blog\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/wagnerbianchi.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=1131"}],"version-history":[{"count":41,"href":"http:\/\/wagnerbianchi.com\/blog\/index.php?rest_route=\/wp\/v2\/posts\/1131\/revisions"}],"predecessor-version":[{"id":1190,"href":"http:\/\/wagnerbianchi.com\/blog\/index.php?rest_route=\/wp\/v2\/posts\/1131\/revisions\/1190"}],"wp:attachment":[{"href":"http:\/\/wagnerbianchi.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=1131"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/wagnerbianchi.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=1131"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/wagnerbianchi.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=1131"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}