This page needs a newer browser to run its tools. You can still read everything here.

Upgrades: 8.4 LTS to 9.7 LTS and 26.x interview questions

Interview questions on “Upgrades: 8.4 LTS to 9.7 LTS and 26.x”: warm-ups, then what each harder question tests and how a good answer starts.

7 questions: 2 warm-ups and 5 with model answers · Levels: Fresher to staff

Warm-up questions

Short questions with short answers, each answered in full.

Fresher

Why can an 8.4.11 server not step directly to 26.7.0, and what does its error log say?

Answered in the lesson MySQL upgrade paths: 8.0 to 8.4, 9.7 and 26.x
Fresher

The MySQL Shell upgrade checker reported one error on an authMethodUsage check. What does that mean, and what do you do before the upgrade?

Answered in the lesson MySQL upgrade paths: 8.0 to 8.4, 9.7 and 26.x

Questions with model answers

What each question tests, the first step of a good answer and the follow-ups to expect.

Mid to senior

A retail service runs 400 GB on MySQL 8.0 and must reach 26.7 within three two-hour maintenance windows over a month. It has one primary and three replicas, with reads already on a replica tier. How do you plan the move, which method do you pick for each window, and where does rollback live?
What it tests

Mapping the lineage rule onto a real plan with replicas, picking an in-place or logical hop per window, and building the rollback into the plan rather than treating it as a command.

First step

Lay the three hops out separately: 8.0 to 8.4, 8.4 to 9.7 and 9.7 to 26.7 are each a supported one-step path (the last because 9.7 is the only line that steps into the first calendar lineage), and each fits a window in place. Replicas go first on every hop, with a labelled snapshot before each slow shutdown.
Follow-ups
- Which window do you spend on which hop, and what reserves time for the longest step?
- How do you prove each hop before moving writes to it, and what triggers a rollback?
- While the upgraded replicas apply events from the older primary, what can still break in that supported direction, and how does the plan catch it before the switchover?
- What is the one thing the plan takes from the source server before the slow shutdown, and why is it the rollback artefact?
From the lesson MySQL upgrade paths: 8.0 to 8.4, 9.7 and 26.x
Model answer, Pro. Model answers open with any pass; prices are in the notice on this page.
Opening the model answers with your pass…
Model answers open with any MySmartCoPilot pass.
Pro pass · 1 week₹79$2.99
30 days₹179$5.99
1 year₹1,699$45
One payment; a pass never renews. The price shown is the total you pay: no fees or charges are added at checkout.
Passes can’t be bought right now, so the model answers can’t be opened at the moment. If you have a pass, enter your licence key.
Choose a pass I have a licence key
It also opens every other in-depth part in Learn and every Pro tool. Sales are final, except where the law gives you a right to withdraw, for example in the EU and the UK (refund policy).
In the answer:
- Model answer
- Common mistakes
- Rubric
- Variants
- about 7 minutes
Mid to senior

After a 9.7.2 upgrade on the primary, the application sees a wrong result from a query that worked on 8.4.11. The team is unsure whether to spend the night debugging or roll back. How do you decide, and if you do roll back how do you bring the service back onto 8.4.11?
What it tests

Reading the rollback decision from the plan (criteria, backup label, a fallback replica held on the old line) rather than improvising, and restoring 8.4.11 from the backup because it cannot start on an upgraded directory.

First step

Read the written criteria the plan set before the upgrade: wrong results on a mapped query is one of them, so the decision is already made. Freeze writes, confirm the labelled backup is readable, and start the restore of 8.4.11 onto a fresh data directory from the backup.
Follow-ups
- How do you show, the next day, that the wrong result comes from the version change and not from the data?
- The plan held one replica on 8.4.11, detached before the primary moved. Can it stand in while the primary is restored, and what does it lack?
- What goes into the labelled backup, and when is a logical dump a better rollback artefact than a physical copy?
- How do you move the fix forward (a new 9.7.2 upgrade) without repeating the same mistake?
From the lesson MySQL upgrade paths: 8.0 to 8.4, 9.7 and 26.x
Model answer, Pro.
In the answer:
- Model answer
- Common mistakes
- Rubric
- Variants
- about 6 minutes
Mid to senior

After an upgrade from MySQL 8.4 to 9.7, a checkout service logs ERROR 1785 on some orders, yet every order row is there and no transaction reports a failed COMMIT. A daily report of page hits now shows gaps. What happened, and how do you fix it without giving up GTIDs?
What it tests

Reading ERROR 1785 as a refused non-transactional write inside a transaction, knowing the InnoDB part still commits, and choosing a fix that keeps GTID consistency instead of switching it off.

First step

Find the transaction the error names: it wrote a non-transactional table after InnoDB writes. With enforce_gtid_consistency ON, only that statement is refused and the rest commits, so the hit rows are the ones lost. Convert the table to InnoDB or move the write out of the transaction, then search the test logs for every other 1785.
Follow-ups
- Why does the COMMIT succeed after the error, and what does that mean for code that ignores errors?
- Why is setting enforce_gtid_consistency back to OFF a poor fix here?
- How do you find every other transaction that mixes engines before the next server moves?
- Which other 9.7 default would a reporting tool that parses EXPLAIN notice first?
From the lesson What changes after MySQL 8.4: 9.7 and 26.7
Model answer, Pro.
In the answer:
- Model answer
- Common mistakes
- Rubric
- Variants
- about 4 minutes
Mid to senior

After moving a staging server from MySQL 8.4 to 9.7, the foreign-key tests of an order service still pass, because every refused insert returns ERROR 1452 as before. A colleague says the foreign-key change of 9.6 is therefore harmless for the service. What do you test before agreeing?
What it tests

Knowing that an unchanged error code can hide a change of enforcer, and testing the behaviour around the error rather than the code alone.

First step

Agree that ERROR 1452 is unchanged, then point out that the enforcer moved from InnoDB to the SQL layer, so what happens around the refusal can differ. List what the service relies on near its foreign keys (generated ids, cascades, and the triggers and feeds that watch them) and give each one a test on a 9.7 copy.
Follow-ups
- What happens to the next AUTO_INCREMENT value after a refused insert on each version, and which tests care?
- Which cascaded actions fire the child table's triggers on 9.7, and what decides it?
- What does a change-data-capture consumer of the binary log receive from a cascade on 9.7?
- When would you set innodb_native_foreign_keys back to ON, and what does that cost?
From the lesson What changes after MySQL 8.4: 9.7 and 26.7
Model answer, Pro.
In the answer:
- Model answer
- Common mistakes
- Rubric
- Variants
- about 5 minutes
Senior to staff

You own the upgrade of 40 MySQL 8.4 Community servers to 9.7 and later 26.7. Teams ask for vector search, JavaScript stored programs and the thread pool, and two clusters run Group Replication. How do you plan which features each team gets, on which version and edition, and what you check before the first server moves?
What it tests

Matching each feature to the version and edition that has it, spotting the one that needs Enterprise and the one no edition offers, and pinning cluster settings before a rolling upgrade.

First step

Sort the requests by edition first: JavaScript stored programs need the Multilingual Engine of Enterprise Edition, the thread pool is Community from 26.7.0, and VECTOR columns work on Community while DISTANCE() is in no edition. Then order the work by version, and pin the Group Replication communication stack before any member moves to 26.7, because its default changes there and members must agree.
Follow-ups
- How does the vector team rank results on a Community server, and what does that cost as the table grows?
- What happens when a dump with JavaScript routines is loaded into a Community server?
- Which version do you plan the thread pool for, and how do you confirm that it loaded?
- What goes into every Group Replication member's option file before the first member moves to 26.7, and why?
From the lesson What changes after MySQL 8.4: 9.7 and 26.7
Model answer, Pro.
In the answer:
- Model answer
- Common mistakes
- Rubric
- Variants
- about 5 minutes

All MySQL & MariaDB in Depth interview questions · The MySQL & MariaDB in Depth track

Warm-up questions

Why can an 8.4.11 server not step directly to 26.7.0, and what does its error log say?

The MySQL Shell upgrade checker reported one error on an authMethodUsage check. What does that mean, and what do you do before the upgrade?

Questions with model answers

A retail service runs 400 GB on MySQL 8.0 and must reach 26.7 within three two-hour maintenance windows over a month. It has one primary and three replicas, with reads already on a replica tier. How do you plan the move, which method do you pick for each window, and where does rollback live?

After a 9.7.2 upgrade on the primary, the application sees a wrong result from a query that worked on 8.4.11. The team is unsure whether to spend the night debugging or roll back. How do you decide, and if you do roll back how do you bring the service back onto 8.4.11?

After an upgrade from MySQL 8.4 to 9.7, a checkout service logs ERROR 1785 on some orders, yet every order row is there and no transaction reports a failed COMMIT. A daily report of page hits now shows gaps. What happened, and how do you fix it without giving up GTIDs?

After moving a staging server from MySQL 8.4 to 9.7, the foreign-key tests of an order service still pass, because every refused insert returns ERROR 1452 as before. A colleague says the foreign-key change of 9.6 is therefore harmless for the service. What do you test before agreeing?