Closed Bug 1530010 Opened 5 years ago Closed 5 years ago

Drop support for dangerous 'utf8' characterset in favor of 'utf8mb4'

Categories

(bugzilla.mozilla.org :: Developer Box, enhancement)

Staging
enhancement
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: imadueme, Assigned: dylan)

Details

Attachments

(1 file)

(This is happening using the latest database dump provided by ops. Happens using master - cfcf11566cb633d68c9b89b032a86a1370ab2943 commit. Possibly could happen on production depending on the root cause).

$answer{'utf8'} = 'utf8mb4'; set in vagrant_support\checksetup_answers.j2.

mysql> SELECT CCSA.character_set_name FROM information_schema.`TABLES` T,
   ->        information_schema.`COLLATION_CHARACTER_SET_APPLICABILITY` CCSA
   -> WHERE CCSA.collation_name = T.table_collation
   ->   AND T.table_schema = "bugs"
   ->   AND T.table_name = "bugs_activity";

+--------------------+
| character_set_name |
+--------------------+
| utf8mb4            |
+--------------------+

1 row in set (0.00 sec)

^confirms that the charset is utf8mb4.

Upon running vagrant up and observing that the web vm was taking a long time to complete checksetup I found these commands running on the db box:

ALTER TABLE bugs_activity MODIFY COLUMN removed varchar(255) CHARACTER SET binary, MODIFY COLUMN added varchar(255) CHARACTER SET binary (completed in about ~30 minutes)

then

ALTER TABLE bugs_activity MODIFY COLUMN removed varchar(255) CHARACTER SET utf8 COLLATE utf8_general_ci, MODIFY COLUMN added varchar(255) CHARACTER SET utf8 COLLATE utf8_general_ci, DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci (still running as of filing this bug)

The schema for the bugs_activity table on bugzilla-dev shows:

mysql> desc bugs_activity;

+------------+---------------------+------+-----+-------------------+----------------+
| Field      | Type                | Null | Key | Default           | Extra          |
+------------+---------------------+------+-----+-------------------+----------------+
| bug_id     | mediumint(9)        | NO   | MUL | NULL              |                |
| who        | mediumint(9)        | NO   | MUL | NULL              |                |
| fieldid    | mediumint(9)        | NO   | MUL | NULL              |                |
| removed    | varchar(255)        | YES  | MUL | NULL              |                |
| added      | varchar(255)        | YES  | MUL | NULL              |                |
| attach_id  | bigint(20) unsigned | YES  | MUL | NULL              |                |
| comment_id | int(11)             | YES  | MUL | NULL              |                |
| id         | int(11)             | NO   | PRI | NULL              | auto_increment |
| bug_when   | timestamp           | NO   | MUL | CURRENT_TIMESTAMP |                |
+------------+---------------------+------+-----+-------------------+----------------+

9 rows in set (0.01 sec)

It is not clear why mysql/checksetup is running these commands.

Attached file GitHub Pull Request
Assignee: nobody → dylan

we're past the point where we need to care about the utf8 charset, so for us now there is only utf8mb4. I believe this means non-utf8 databases will be upgraded by checksetup.

Summary: checksetup seemingly doing unncessary and long running db operations → Drop support for dangerous 'utf8' charactset in favor of 'utf8mb4'
Summary: Drop support for dangerous 'utf8' charactset in favor of 'utf8mb4' → Drop support for dangerous 'utf8' characterset in favor of 'utf8mb4'
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: