Update deprecated links

Update deprecated links in TwoPhaseCommitDesign.md

Signed-off-by: huynq0911 <[email protected]>

Author: huynq0911

doc/TwoPhaseCommitDesign.md

@@ -19,7 +19,11 @@ This document intends to address the above concerns with some practical trade-of
 
 Although MySQL supports the XA protocol, it’s been unusable due to bugs. Version 5.7 claims to have fixed them all, but the more common versions in use are 5.6 and below, and we need to make 2PC work for those versions also. Even at 5.7, we still have to contend with the chattiness of XA, and the fact that it’s unused code.
 
+<<<<<<< Updated upstream
 The most critical component of the 2PC protocol is the ‘Prepare’ functionality. There is actually a way to implement Prepare on top of a transactional system. This is explained in a [Vitess Blog](http://blog.vitess.io/2016/06/distributed-transactions-in-vitess_7.html), which will be used as foundation for this design.
+=======
+The most critical component of the 2PC protocol is the ‘Prepare’ functionality. There is actually a way to implement Prepare on top of a transactional system. This is explained in a [Vitess Blog](https://vitess.io/blog/2016-06-07-distributed-transactions-in-vitess/), which will be used as foundation for this design.
+>>>>>>> Stashed changes
 
 Familiarity with the blog and the [2PC algorithm](http://c2.com/cgi/wiki?TwoPhaseCommit) are required to understand the rest of the document.
 
@@ -32,7 +36,11 @@ Vitess will add a few variations to the traditional 2PC algorithm:
     * The Coordinator will be stateless and will orchestrate the work. VTGates are the perfect fit for this role.
     * One of the VTTablets will be designated as the Metadata Manager (MM). It will be used to store the metadata and perform the necessary state transitions.
 * If we designate one of the participant VTTablets to be the MM, then that database can avoid the prepare phase: If you assume there are N participants, the typical explanation says that you perform prepares from 1->N, and then commit from 1->N. If we instead went from 1->N for prepare, and N->1 for commit. Then the N’th database would perform a Prepare->Decide to commit->Commit. Instead, we execute the DML needed to transition the metadata state to ‘Decide to Commit’ as part of the app transaction, and commit it. If the commit fails, then it’s treated as the prepare having failed. If the commit succeeds, then it’s treated as all three operations having succeeded.
+<<<<<<< Updated upstream
 * The Prepare functionality will be implemented as explained in the [blog](http://blog.vitess.io/2016/06/distributed-transactions-in-vitess_7.html).
+=======
+* The Prepare functionality will be implemented as explained in the [blog](https://vitess.io/blog/2016-06-07-distributed-transactions-in-vitess/).
+>>>>>>> Stashed changes
 
 Combining the above changes allows us to keep the most common use case efficient: A transaction that affects only one database incurs no additional cost due to 2PC.
 
@@ -146,7 +154,11 @@ The DTID will be generated by taking the VTID of the MM and prefixing it with th
 
 ## Prepare API
 
+<<<<<<< Updated upstream
 The Prepare API will be provided by VTTablet, and will follow the guidelines of the [blog](http://blog.vitess.io/2016/06/distributed-transactions-in-vitess_7.html). It’s essentially three functions: Prepare, CommitPrepared and RollbackPrepared.
+=======
+The Prepare API will be provided by VTTablet, and will follow the guidelines of the [blog](https://vitess.io/blog/2016-06-07-distributed-transactions-in-vitess/). It’s essentially three functions: Prepare, CommitPrepared and RollbackPrepared.
+>>>>>>> Stashed changes
 
 ### Statement list and state