SELECT FOR UPDATE 在迁移期间锁定数据库

SELECT FOR UPDATE to lock database during migration

我试图在数据库迁移期间阻止并发修改,我的方法是使用 SELECT ... FOR UPDATE 锁定现有的 table t (prereq) 并在锁定期间实现迁移。

因此我创建了一个简单的示例,如下所示:

Connection conn = DriverManager.getConnection("jdbc:mysql://127.0.0.1:3306/testdb", "root", "");

conn.setAutoCommit(false);
statement = conn.createStatement();
ResultSet rs = statement.executeQuery("SELECT id FROM t FOR UPDATE");
rs.next();
System.out.println(rs.getInt(1));

System.out.println("Sleeping...");
Thread.sleep(10000);

statement.executeUpdate("CREATE TABLE t2 (id int PRIMARY KEY)");
// Release lock
statement.executeUpdate("UPDATE t SET id = 2 WHERE id = 1");

conn.commit();

statement.close();
conn.close();

其中 t 是一个只有 id int PRIMARY KEY.

的虚拟 table

我设置了一个Thread.sleep(10000);来模拟长进程。 Thread.sleep(10000);期间我运行秒(类似的一段代码)来模拟并发

Connection conn = DriverManager.getConnection("jdbc:mysql://127.0.0.1:3306/testdb", "root", "");

Statement statement = conn.createStatement();
conn.setAutoCommit(false);
statement = conn.createStatement();
ResultSet rs = statement.executeQuery("SELECT id FROM t FOR UPDATE");
rs.next();
System.out.println(rs.getInt(1));

conn.commit();

statement.close();
conn.close(); 

但我希望代码打印 2.. 它打印 1.

当我检查 MySQL 通用日志时,我看到了那个东西

438 Query   SET autocommit=0
438 Query   SELECT id FROM t FOR UPDATE
439 Query   /* mysql-connector-java-5.1.35 ( Revision: 5fb9c5849535c13917c2cf9baaece6ef9693ef27 ) */SHOW VARIABLES WHERE Variable_name ='language' OR Variable_name = 'net_write_timeout' OR Variable_name = 'interactive_timeout' OR Variable_name = 'wait_timeout' OR Variable_name = 'character_set_client' OR Variable_name = 'character_set_connection' OR Variable_name = 'character_set' OR Variable_name = 'character_set_server' OR Variable_name = 'tx_isolation' OR Variable_name = 'transaction_isolation' OR Variable_name = 'character_set_results' OR Variable_name = 'timezone' OR Variable_name = 'time_zone' OR Variable_name = 'system_time_zone' OR Variable_name = 'lower_case_table_names' OR Variable_name = 'max_allowed_packet' OR Variable_name = 'net_buffer_length' OR Variable_name = 'sql_mode' OR Variable_name = 'query_cache_type' OR Variable_name = 'query_cache_size' OR Variable_name = 'license' OR Variable_name = 'init_connect'
439 Query   /* mysql-connector-java-5.1.35 ( Revision: 5fb9c5849535c13917c2cf9baaece6ef9693ef27 ) */SELECT @@session.auto_increment_increment
439 Query   SET character_set_results = NULL
439 Query   SET autocommit=1
439 Query   SET sql_mode='NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES'
439 Query   SET autocommit=0
439 Query   SELECT id FROM t FOR UPDATE
438 Query   CREATE TABLE t2 (id int PRIMARY KEY)
439 Query   commit
439 Query   rollback
439 Quit    
438 Query   UPDATE t SET id = 2 WHERE id = 1
438 Query   commit
438 Query   rollback

CREATE TABLE t2... 事务(会话 2)提交后释放锁,但我在 autoCommit(false) 为什么 MySQL 在这种情况下强制 commit

我可能还误解了 SELECT ... FOR UPDATE 的工作原理...


更新:在没有 Java 和 JDBC 的情况下使用 mysql 客户端

进行了测试
SESSION1> CREATE TABLE t (id int PRIMARY KEY) ENGINE=INNODB;
SESSION1> INSERT INTO t VALUES (1);
SESSION1> BEGIN;
SESSION1> SELECT id FROM t FOR UPDATE;

SESSION2> BEGIN;
SESSION2> SELECT id FROM t FOR UPDATE;
--> HERE SESSION2 is stuck (expected behavior)

SESSION1> CREATE TABLE t2 (id int PRIMARY KEY) ENGINE=INNODB;
--> HERE SESSION2 is unlock returning 
+----+
| id |
+----+
|  1 |
+----+
1 row in set (4.15 sec)

似乎SELECT ... FOR UPDATE with DLL 语句没有像我预期的那样工作

如果您的存储引擎是 MyISAM,您将观察到此行为。 MyISAM 不支持事务,因此,您的第一个代码不会放置任何锁,因为所有语句都会自动提交,因此您的第二个代码将愉快地游过自己的 SELECT FOR UPDATE 并直接进行 SELECT ID。

长话短说:将数据库切换到 InnoDB 存储以使其正常工作。

参考文献:

https://dev.mysql.com/doc/refman/5.0/en/myisam-storage-engine.html

https://dev.mysql.com/doc/refman/5.5/en/innodb-storage-engine.html

最终无法在独占锁 (SELECT ... FOR UPDATE) 期间创建类似 CREATE TABLE 的 DLL 语句。

然而,为了满足我的需求,我将使用与 flyway 相同的策略。事实上,flyway 使用了两个会话:

  1. 要锁定的 Metatable 会话(Metatable 是 flyway 的核心 table)
  2. 对象会话执行迁移

因此具有不同的会话锁定机制,可以使用mysql cli进行模拟

SESSION-METATABLE> CREATE TABLE t (id int PRIMARY KEY) ENGINE=INNODB;
SESSION-METATABLE> INSERT INTO t VALUES (1);
SESSION-METATABLE> BEGIN;
SESSION-METATABLE> SELECT id FROM t FOR UPDATE;

SESSION-CONCURRENT> BEGIN;
SESSION-CONCURRENT> SELECT id FROM t FOR UPDATE;
--> HERE SESSION-CONCURRENT is stuck (expected behavior)

SESSION-OBJECT> BEGIN;
SESSION-OBJECT> CREATE TABLE t2 (id int PRIMARY KEY);
--> HERE SESSION-CONCURRENT is not unlock
SESSION-OBJECT> COMMIT;
--> SESSION-CONCURRENT still stuck even after COMMIT;

SESSION-METATABLE>UPDATE t SET id=2 WHERE id=1;
SESSION-METATABLE>COMMIT;
--> HERE SESSION-CONCURRENT is unlock and print
+----+
| id |
+----+
|  2 |
+----+
1 row in set (23.33 sec)