Private corporate batches, live online cohorts and 1-on-1 mentoring in MySQL administration, replication, backup and recovery, and performance tuning in production — taught by a practitioner who runs it in production.
20 years across DevOps, SRE and Security · 10,000+ engineers trained · Trained teams at JPMorgan Chase, Verizon, Nokia and the World Bank
Principal DevOps Engineer & Architect
Rajesh teaches MySQL as an operational system rather than a query language: the InnoDB buffer pool, redo and undo mechanics that explain most performance behaviour; GTID replication and the migration path away from file-and-position; logical versus physical backup with point-in-time recovery actually performed rather than described; and execution plans read from EXPLAIN rather than guessed at. Sessions deliberately cover the failures that decide an on-call night — replication lag, lock waits, a diverged replica, an online schema change on a hot table, and a restore nobody had ever tested.
Twenty years across DevOps, SRE and Security, in principal and architect roles at PayPay, SoftwareAG, ServiceNow, JDA Software, Intuit, Adobe and others. He has trained engineers at JPMorgan Chase, Verizon, Nokia, the World Bank, VMware, Oracle, Mercedes-Benz and Airbus — more than 10,000 people personally. He teaches what he runs, not what he reads.
You are booked with a named engineer, and that is who turns up. Marketplaces and larger providers rotate whoever is free, so the person who sold you the agenda is rarely the person teaching it.
The same trainer is available for the next engagement, which matters when a team builds on what it learned last time.
Your batch is assigned a named trainer before it starts, and that is who teaches it. See the full faculty.
Engagements are matched on the tool, not the calendar. For MySQL that means a trainer who has run it in production — MySQL administration, replication, backup and recovery, and performance tuning in production — rather than whoever is free that week. You are told who is teaching before you commit, and that person is on the discovery call that shapes the agenda.
Where a batch is large enough to need a second trainer, the pairing is declared up front. The lead trainer stays accountable for the syllabus and the assessment either way.
Principal DevOps Engineer & Architect
Twenty years across DevOps, SRE and Security in principal and architect roles at PayPay, SoftwareAG, ServiceNow, JDA Software, Intuit, Adobe, IBM/Emptoris, Ness, MindTree and Accenture. He has trained more than 10,000 engineers personally, at organisations including JPMorgan Chase, Verizon, Nokia, the World Bank, VMware, Oracle, Mercedes-Benz and Airbus. He teaches what he runs, not what he reads.
Teams of 8–30
Custom agenda, your timezone, onsite or online, NDA-friendly.
Request a quoteIndividual engineers
A private instructor and a curriculum built around your goal.
₹99,999Individuals who want peers
Scheduled batch, max 8 to 10 hours of live instruction.
₹34,999A private batch starts with a discovery call. We look at the stack you actually run — the CI system, the cloud, the constraints — and map the agenda onto it, so examples use your topology rather than a generic one.
Delivery is onsite at your premises, live online, or hybrid, scheduled around your release calendar rather than ours. Batches run 8 to 30 engineers.
Every attendee leaves with recordings, slides, lab repositories and a completion certificate. You receive an attendance and assessment report. Invoicing supports PO and GST.
Talk to us about a private MySQL batchMySQL is an open-source relational database management system built around a pluggable storage engine architecture, with InnoDB as the default engine. InnoDB is what gives MySQL its operational character: a transactional, MVCC-based engine with a buffer pool that caches pages in memory, a redo log that makes commits durable, undo logs that serve consistent reads, and row-level locking that decides how much concurrency the server can actually sustain.
For an infrastructure team, MySQL is less a query language than a set of moving parts to keep running. The binary log drives both point-in-time recovery and replication. Replicas can be asynchronous, semi-synchronous, or coordinated through Group Replication, and GTIDs turn failover and topology changes into something reasoned about rather than reconstructed by hand from file-and-position coordinates. Configuration lives in my.cnf, with a growing set of variables changeable online through SET PERSIST, while performance_schema, sys and the data dictionary expose what the server is doing while it does it.
MySQL turns up almost everywhere — behind web applications, as the metadata store for other infrastructure, and as the engine underneath managed services such as Amazon RDS, Aurora, Cloud SQL and Azure Database for MySQL. Those services remove the host, not the database. Buffer pool sizing, index selection, replication lag, lock contention, schema change under load and backups nobody has restored remain the operator's problem no matter who runs the instance.
Almost every organisation runs a relational database it cannot afford to lose, and MySQL is the one it most often turns out to be. The dedicated DBA role, meanwhile, has largely dissolved into platform and SRE teams — which means the people now carrying the pager for a database were rarely trained on one.
That gap shows up in a predictable set of incidents: a replica that has been lagging for a week and nobody alerted on it, an ALTER TABLE that locked a production table at peak, a backup job that has been green for two years and has never been restored, a buffer pool sized at the package default on a machine with 64GB of RAM. None of these are exotic. All of them are avoidable by someone who understands what InnoDB is doing underneath.
Managed services have raised the floor without removing the requirement. RDS and Aurora will fail over for you, but they will not choose your indexes, size your instance class against your working set, explain why your replica lag spikes at 02:00, or tell you that your point-in-time recovery window is shorter than your detection time. Teams increasingly hire for exactly that judgement — operational MySQL depth attached to infrastructure and automation skills, rather than a pure query-writing background.
How the server is actually put together — connection layer, parser, optimiser, and the pluggable storage engine boundary that explains why InnoDB and MyISAM behave so differently. Installation via package manager and manual tarball, directory layout, and what an in-place upgrade to MySQL 8 changes underneath you.
Topics: MySQL server architecture and the storage engine layer · Installation via package manager · Installation from a manual package or tarball · Directory layout, datadir and file roles · Upgrading an existing database to MySQL 8 · Client tools: mysql, mysqladmin, mysqldump, MySQL Shell
Where configuration comes from and which setting wins. my.cnf sections and precedence, global versus session variables, online changes with SET PERSIST, and the small set of parameters that determine most of a server's behaviour. Then the data dictionary and information_schema as the introspection surface.
Topics: my.cnf structure, sections and precedence · Global, session and persisted variables · Changing configuration online with SET PERSIST · The parameters that matter: buffer pool, log file size, flush method, connections · Accessing the data dictionary and information_schema · Server logs: error, general, slow query
The engine underneath almost every production table. Buffer pool structure and warm-up, the redo log and the flush cycle, undo logs and MVCC, isolation levels and what each one actually costs, row-level locking, gap locks, and how deadlocks are detected and reported.
Topics: Buffer pool structure, sizing and warm-up · Redo log, checkpointing and innodb_flush_log_at_trx_commit · Undo logs, MVCC and consistent reads · Transaction isolation levels in practice · Row locks, gap locks and next-key locks · Reading SHOW ENGINE INNODB STATUS · Deadlock detection and diagnosis
Access control that survives review. Creating databases and application users properly, the MySQL 8 role model, authentication plugin changes and what they break in older clients, TLS for client and replication connections, and the audit trail an infrastructure team is expected to produce.
Topics: Creating databases and users for applications · Managing users, hosts and account expiry · Roles in MySQL 8 and least-privilege grant design · Authentication plugin changes and legacy client compatibility · TLS for client and replication traffic · Auditing, connection control and password policy
You do not have to write the application's queries, but you do have to explain why they are slow. Data types and their storage cost, schema design decisions that later become operational problems, the query patterns that defeat indexes, and the MySQL 8 features — CTEs, window functions — that change what the optimiser can do.
Topics: Data types, storage cost and implicit conversion traps · Schema design decisions with operational consequences · Querying and modifying data: the patterns operators see most · Query anti-patterns that defeat indexes · CTEs and window functions in MySQL 8 · Writing queries that are safe to run on production
The core performance work. How B-tree indexes are actually used, composite index column order and the leftmost-prefix rule, covering indexes, index selectivity, and when an index makes things worse. Then EXPLAIN and EXPLAIN ANALYZE read properly, and partitioning for genuinely large tables.
Topics: B-tree indexes, composite indexes and leftmost prefix · Covering indexes and index-only scans · Selectivity, cardinality and optimiser statistics · Reading EXPLAIN and EXPLAIN ANALYZE · Optimiser hints and when to use them · Managing big tables with partitioning · Index maintenance cost on write-heavy workloads
The part that is only ever tested once, usually badly. Logical backups with mysqldump and mysqlpump, physical backups with Percona XtraBackup or MySQL Enterprise Backup, the binary log as the recovery timeline, and a point-in-time recovery performed end to end rather than described.
Topics: The binary log: formats, retention and purging · Logical backups: mysqldump, mysqlpump and consistency · Physical backups: XtraBackup, snapshots and clone · Point-in-time recovery from a full backup plus binlogs · Backup verification and restore rehearsal · RPO and RTO stated as numbers, not intentions
How MySQL copies data, and everything that can go wrong while it does. Setting up a replica, binary log formats and their replication consequences, parallel replication workers, replication lag and its real causes, GTID replication and migrating an existing file-and-position topology to it.
Topics: Setting up a replication replica from a backup · Binary log formats: statement, row and mixed · Replication threads, parallel workers and lag · Introduction to GTID replication · Migrating an existing topology to GTID · Semi-synchronous replication and its cost · Checking replication consistency with checksums
Knowing the server is unhealthy before the application does. Command-line diagnosis, performance_schema and the sys schema, the slow query log and digest analysis, external monitoring with Prometheus exporters and Grafana, and generating realistic load with sysbench so tuning claims can be measured.
Topics: Command line monitoring: SHOW PROCESSLIST, status and engine status · performance_schema and the sys schema · Slow query log and digest-based analysis · External monitoring: exporters, Prometheus and Grafana · The alerts a MySQL estate actually needs · Load testing with sysbench · Performing basic troubleshooting under pressure
Keeping the database available while it changes. Planned switchover and unplanned failover, orchestration with tools such as Orchestrator and MySQL Router or ProxySQL in front of the topology, online schema change, and migration planning — including verifying query behaviour and replication consistency before you cut over.
Topics: Planned switchover versus unplanned failover · Group Replication and InnoDB Cluster · Proxy layers: ProxySQL and MySQL Router · Online schema change with gh-ost or pt-online-schema-change · Migration considerations and cutover planning · Replication consistency before migration · Verifying query behaviour before migration
We rebuild the agenda around the tools you actually run.
Request a custom agendaDrive a benchmarked workload against three buffer pool sizes, then deliberately create lock waits and deadlocks and diagnose them from InnoDB status alone.
Take a set of genuinely slow production-shaped queries and fix each one using EXPLAIN and index design, with no schema or hardware changes permitted.
Restore a full physical backup, replay binary logs to the transaction immediately before an accidental DELETE, and report the real recovery time.
Build a three-node asynchronous topology, migrate it to GTID replication without downtime, then verify consistency with table checksums.
Put ProxySQL in front of a replica set and perform a planned switchover while a client workload keeps running, measuring the error window.
Take a monitored three-node estate through an online schema change, a replica failure, a lag incident and a restore drill, documenting each intervention.
Billed yearly at ₹9,996
Max 8 to 10 hours of live instruction
Full program, private instructor
8–30 engineers · custom agenda · onsite or online · PO and GST invoicing
Refunds. If we cancel or postpone a cohort, you get a full refund within 15 days. There is no money-back guarantee otherwise.
Terms. Course material remains licensed to the attendee. Read the terms.
Your data. We don't share it with third parties. Privacy policy.
Certificate of completion
The trainer (Rajesh) provided very good sessions on SRE profession. Not only hands-on learning on the tools but also SRE mindset.
Very good training session. Well explained from the basics to the complex concepts. Also tried to cover practicals and demos within the 3 hour sessions. The learning content and videos are of a great deal of help.
Basics explanation was exemplary from Rajesh where he dealt with complicated topics to be simple. Great learning stuff personally for me.
Very detailed explanation and has lots of patience in attending the questionnaire. Thanks again for your wonderful sessions.
Good discussion, helped us to understand different tools in SRE.
Got good lab sessions which kept the new DevOps tool learnings to the point and it helped a lot in my career.
| What matters | YouTube + blogs | Generic online course | Freelance marketplace | DevOpsSchool |
|---|---|---|---|---|
| Named practitioner | No | Rarely | Varies per booking | Yes — same trainer each time |
| Production experience | Unknown | Unknown | Unverified | 20 years, named employers |
| Custom agenda | No | No | Sometimes | Built from your stack |
| Onsite delivery | No | No | Sometimes | Yes |
| Lab environment | None | Sandbox that expires | Varies | Your own cloud — skill goes with you |
| Assessment | None | Quiz | Rarely | Assignments + capstone per module |
| Per-attendee certificates | No | Sometimes | Rarely | Yes |
| Corporate invoicing | No | Limited | Varies | PO and GST |
| Post-training support | None | Forum, time-limited | None | Lifetime forum access |
Tell us the team, the stack and the timeline. You'll get a straight answer, not a sales sequence.
Talk to an advisorPrefer to call or email?
More ways to reach us on the contact page.