【MySQL】UUID與GTID以及如何根據GTID找尋filename和position

  UUID()

Open Group於1997年10月釋出，UUID遵從此協議。 UUID被設計成一個在空間和時間上的唯一值。兩次呼叫的UUID將產生兩個不同的值，即使這些呼叫是在兩個不連線的，彼此獨立的計算機。 由一串數字表示 aaaaaaaa-bbbb-cccc - dddd - eeeeeeeeeeee   format:

mysql> SELECT UUID(); -> '6ccd780c-baba-1026-9564-0040f4311e29'

雖然UUID（）值是唯一的，但它們不一定是不可猜測的或不可預測的。如果需要不可預測性，UUID值應該以其他方式生成。 UUID 不基於statement replication.

• The first three numbers are generated from a timestamp.

• The fourth number preserves temporal uniqueness in case the timestamp value loses monotonicity (for example, due to daylight saving time).
  由於夏令時導致的

• The fifth number is an IEEE 802 node number that provides spatial uniqueness. A random number is substituted if the latter is not available (for example, because the host computer has no Ethernet card, or we do not know how to find the hardware address of an interface on your operating system). In this case, spatial uniqueness cannot be guaranteed. Nevertheless, a collision should have  very  low probability.
  第五個數字是，它提供空間唯一一個IEEE802節點號。

  The MAC address of an interface is taken into account only on FreeBSD and Linux. On other operating systems, MySQL uses a randomly generated 48-bit number.

• uuid我在百度百科上也看到了... ...

• 
  

• 第 1 2 3  段是與時間有關的。

  time_low 、 time_mid 、 time_high_and_version 轉成 16 進位制後分別對應第 1 2 3 段。這個時間是從 1582-10-15 00:00:00.00 到當前時間的 100ns 值。（實際上系統只能取到精確 us ，再乘以 10 ）。所以你短時間連續執行的話，比較可能只有第一個值在改，實際上 1 2 3 都可能會改變。

  第 4 段是你啟動這個 MySQL 後第一次執行 select uuid() 時的隨機數，每次重啟會改變。

  第 5 段是 mac 值轉過來的，同一個機器多例項的一般相同。如果 mac 值獲取不到，則是一個隨機值。

  所以這個值可以認為是每次執行都不相同。並且不同例項之間也只有極微小概率重複。

•   UUID_SHORT()

  Returns a  “ short ”  universal identifier as a 64-bit unsigned integer (rather than a string-form 128-bit identifier as returned by the  UUID()  function).

  The value of  UUID_SHORT()  is guaranteed to be unique if the following conditions hold:

  The  UUID_SHORT()  return value is constructed this way:

    (server_id & 255) << 56
  + (server_startup_time_in_seconds << 24)
  + incremented_variable++;
  

  mysql> SELECT UUID_SHORT(); -> 92395783831158784
  

  Note that  UUID_SHORT()  does not work with statement-based replication.

• The  server_id  of the current host is unique among your set of master and slave servers

• server_id  is between 0 and 255

• You do not set back your system time for your server between  mysqld  restarts

  與 uuid 返回固定長度字串不同，  uuid_short 的返回值是一個 unsigned long long 型別。
  MySQL 啟動後第一次執行的值是通過 server_id << 56 + server_start_time << 24 來初始化。 server_start_time 單位是秒。   之後每次執行都加 1 。
  由於每次加 1 都會加全域性 mutex 鎖，因此多執行緒安全，可以當作 sequence 來用，只是初始值有點大。

  
  

• You do not invoke  UUID_SHORT()  on average more than 16 million times per second between  mysqld  restarts

• 
  

    VALUES( col_name )

  In an  INSERT ... ON DUPLICATE KEY UPDATE  statement, you can use the VALUES( col_name ) function in the  UPDATE  clause to refer to column values from the  INSERT  portion of the statement. In other words, VALUES( col_name ) in the  UPDATE  clause refers to the value of  col_name  that would be inserted, had no duplicate-key conflict occurred. This function is especially useful in multiple-row inserts. The  VALUES()  function is meaningful only in the ON DUPLICATE KEY UPDATE clause of  INSERT  statements and returns NULL otherwise. See  Section 13.2.5.3, “INSERT ... ON DUPLICATE KEY UPDATE Syntax” .

  mysql> INSERT INTO table (a,b,c) VALUES (1,2,3),(4,5,6) -> ON DUPLICATE KEY UPDATE c=VALUES(a)+VALUES(b);
  

當開啟gitd時，binlog中會多出gtid event，掃描binlog就會知道GTID對應的filename和position，主從日誌落後很多，就會掃描很多binlog日誌。

Previous_gtids表示這之前的binlog執行到的GTID的位置。GTID比當前值到就去掃這個binlog，比這個小就去掃描之前的binlog日誌。

說到切換，有的時候主庫恢復後，可能從庫還沒有應用完，雖然我們事先準備好了切換指令碼，但是到這時候我們還是很猶豫的，經歷過後會深有感觸。金融行業不允許切半同步，

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/29990276/viewspace-1873291/，如需轉載，請註明出處，否則將追究法律責任。