Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Repair Windows errors before they cause bigger problemsFix Now →Scan for outdated or missing drivers - takes under a minuteDriver Scan →iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Need a server to try this on? Antihost offers Linux VPS plans with NVMe storage, full root access and a 14-day free trial.
For a new high-availability deployment, build a three-member MySQL InnoDB Cluster on separate Linux VPS instances, use MySQL Group Replication for membership and data consistency, and put MySQL Router in front of the servers for application connections. Three members are the practical minimum: a majority survives one node failure, while two-member designs cannot automatically maintain quorum after a single failure.
What you are building
MySQL InnoDB Cluster combines four pieces: MySQL Server instances that store the data, Group Replication that maintains a consistent replicated group, MySQL Shell AdminAPI that configures and manages the group, and MySQL Router that presents stable application endpoints. A common topology is one read/write primary and two read-only secondaries.
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →The application should connect to Router rather than to an individual database server. Router reads cluster metadata, discovers topology changes, and sends read/write connections to the current primary. Read-only routes can be used for workloads that tolerate replica reads. Keep direct node addresses for administration and emergency recovery.
How many VPS nodes do you need?
Three nodes for one-failure tolerance
Use three separate VPS instances for the normal high-availability design. Group Replication needs a majority to make progress. MySQL documents the quorum relationship as n = 2 × f + 1, where n is the number of members and f is the number of involuntary failures the group can tolerate.
#1 Best Overall
- [INTEL POWERED CONTENT] - Built with a 8th Generation Hexa-Core Intel i5 and 32GB of DDR4 RAM; Modern, Windows 11 ready, with 4K support, Executive multitasking, media streaming and smooth, multi-tab web browsing; Perfect as an all-purpose multimedia computer; built for content creators; Plenty of RAM and Mass storage for photo and video editing powered by Intel HD 630
- [LATEST WIRELESS TECH] - This Dell Desktop Computer easily connects to the internet through the Built In WiFi / Bluetooth
- [SOLID STATE STORAGE] - This Dell Computer setup comes with an ultra-fast 1TB Solid State Drive (SSD); Setup as the primary boot device; Boot and load programs with lightning speed ; Additional expansion available
- [BUY & OWN WITH CONFIDENCE] - From the world's largest Microsoft Authorized Refurbisher; Quality Guarantee and Free Tech Support; Award-winning Customer Service; | Support Sustainable Business
- [MODERN HI-SPEED PORTS] - USB 3.0 (x4) | USB 2.0 (x4) | DisplayPort (x1) | HDMI Port (x1) | Audio Combo Jack (x1) | Audio Out (x1) | RJ-45 Ethernet (x1) | Internal SATA (x3)
| Members | Failures tolerated while retaining majority | Operational meaning |
|---|---|---|
| 3 | 1 | One member may fail and the remaining two can continue automatically. |
| 5 | 2 | Useful when the service requires tolerance of two simultaneous member losses. |
| 2 | 0 | A single failure leaves no majority, so automatic progress stops. |
A second failure in a three-member group leaves one of three members. That surviving server cannot make quorum decisions by itself. Adding nodes increases failure tolerance but also increases replication traffic, operational work, and the number of machines that must be kept healthy.
Place the members so one incident does not remove the majority
Put the VPS instances in the same private network when predictable latency is more important than site-level disaster tolerance. If your provider supports independent availability zones with a low-latency private link, distribute members so a single host or zone outage does not remove two members. Do not place all three virtual machines on one physical host when the provider exposes that risk.
Linux VPS prerequisites
Network identity and reachability
- Provision three independent VPS instances, called VPS-1, VPS-2 and VPS-3 below.
- Assign stable private addresses and create forward and reverse name resolution for every member. Use names that resolve identically from all nodes and from the administration host.
- Verify bidirectional connectivity between every pair on the private network. Group Replication must be able to exchange membership and transaction messages in both directions.
- Keep replication traffic on the private interface. Never expose the Group Replication listener to the public internet.
- Choose one administration host for MySQL Shell. It can be a hardened management VPS or an application-tier machine, but it should not become the only place where backups or monitoring run.
Firewall rules and ports
| Traffic | Port and protocol | Allow from | Purpose |
|---|---|---|---|
| SQL client connections | TCP 3306, unless you deliberately choose another port | Application networks, Router hosts and approved administrators | SQL sessions to MySQL Server |
| Group Replication | TCP 33061 | All cluster members only | Internal member-to-member communication; the commonly recommended value for group_replication_local_address |
| MySQL Shell administration | TCP 3306 to the target instance | Management network only | AdminAPI configuration and inspection |
| Router client endpoint | Ports selected during Router bootstrap | Application networks | Stable read/write and, if enabled, read-only endpoints |
Use host firewalls as well as the provider’s network firewall. A typical policy denies inbound traffic by default, permits SSH only from a management range, permits TCP 3306 from trusted application or administration networks, and permits TCP 33061 only between the three private addresses. Restrict Router’s listening ports to application networks.
Operating-system preparation
- Install the same supported MySQL Server release and compatible MySQL Shell release on all members.
- Keep system clocks synchronized; consistent timestamps make incident diagnosis and certificate validation easier.
- Use a dedicated filesystem with sufficient free space for the data directory, binary logs, temporary files and recovery operations.
- Set resource limits and file-descriptor limits appropriate for your connection count, then document them so a rebuilt VPS is equivalent to its predecessor.
- Install monitoring and backup agents before production traffic arrives, but keep their database accounts least-privileged.
MySQL settings every member must share
Group Replication is not a generic asynchronous replica setup. It has specific consistency and identity requirements that must be satisfied on every member.
- InnoDB tables: Store application data in InnoDB. Other storage engines can produce Group Replication errors or behavior that is not safe for the cluster.
- Unique server IDs: Set a different positive
server_idon VPS-1, VPS-2 and VPS-3. - GTIDs: Enable
gtid_mode=ONandenforce_gtid_consistency=ONeverywhere. GTID-based replication is required so committed transactions can be tracked unambiguously. - Consistent case handling: Keep
lower_case_table_namesidentical on every member. A mismatch can make object names behave differently after a failover. - Consistent encryption defaults: Keep
default_table_encryptionaligned across the group. - Row-based replication: Use the row-based replication defaults supported by your selected MySQL release and do not mix incompatible release configurations during an upgrade.
- Group identity: Use one UUID for
group_replication_group_nameon all members, while each member has a unique identity and uniquegroup_replication_local_address. - Separate addresses: The local Group Replication address, normally TCP 33061, is for member traffic. It is not a replacement for the SQL administration address on TCP 3306.
Apply changes consistently, restart when the selected variable requires it, and validate the effective values rather than assuming the configuration file was loaded. A member with a duplicate server ID, a different group name or an unreachable local address will not join correctly.
Creation workflow with MySQL Shell AdminAPI
1. Install matching software
Install the same supported MySQL Server release on all three VPS instances. Install MySQL Shell on the administration host and ensure it can resolve each private hostname and reach the SQL port. Keep package repositories and configuration management under version control so a replacement node can be reproduced.
2. Configure and validate the instances
On each VPS, configure the prerequisites above, create the administrative account that AdminAPI will use, and restart if necessary. Before creating a cluster, test name resolution and connectivity from every node to every other node on TCP 3306 and TCP 33061. A simple TCP test that succeeds in one direction is not enough; all six directed paths must work.
Rank #2
- Entry-level NAS Personal Storage：UGREEN NAS DH2300 is your first and best NAS made easy. It is designed for beginners who want a simple, private way to store videos, photos and personal files, which is intuitive for users moving from cloud storage or external drives and move away from scattered date across devices. This entry-level NAS 2-bay perfect for personal entertainment, photo storage, and easy data backup (doesn't support Docker or virtual machines).
- Set Your Devices Free, Expand Your Digital World: This unified storage hub supports massive capacity up to 64TB.*Storage drives not included. Stop Deleting, Start Storing. You can store 22 million 3MB images, or 2 million 30MB songs, or 43K 1.5GB movies or 67 million 1MB documents! UGREEN NAS is a better way to free up storage across all your devices such as phones, computers, tablets and also does automatic backups across devices regardless of the operating system—Window, iOS, Android or macOS.
- The Smarter Long-term Way to Store: Unlike cloud storage with recurring monthly fees, a UGREEN NAS enclosure requires only a one-time purchase for long-term use. For example, you only need to pay $459.98 for a NAS, while for cloud storage, you need to pay $719.88 per year, $2,159.64 for 3 years, $3,599.40 for 5 years. You will save $6,738.82 over 10 years with UGREEN NAS! *NAS cost based on DH2300 + 12TB HDD; cloud cost based on 12TB plan (e.g. $59.99/month).
- Blazing Speed, Minimal Power: Equipped with a high-performance processor, 1GbE port, and 4GB RAM on Board, this NAS handles multiple tasks with ease. File transfers reach up to 125MB/s—a 1GB file takes only 8 seconds. Don't let slow clouds hold you back; they often need over 100 seconds for the same task. The difference is clear.
- Let AI Better Organize Your Memories: UGREEN NAS uses AI to tag faces, locations, texts, and objects—so you can effortlessly find any photo by searching for who or what's in it in seconds. It also automatically finds and deletes similar or duplicate photo, backs up live photos and allows you to share them with your friends or family with just one tap. Everything stays effortlessly organized, powered by intelligent tagging and recognition.
Check that each instance reports the intended server_id, GTID settings, case and encryption settings, and InnoDB as the storage engine for application tables. Resolve firewall, DNS and certificate problems before proceeding.
3. Run AdminAPI instance checks
Open MySQL Shell on the administration host and connect to VPS-1. AdminAPI can inspect an instance and identify settings that would prevent it from joining. A representative workflow is:
mysqlsh admin@vps-1.example --js
var check = dba.checkInstanceConfiguration('admin@vps-1.example:3306');
checkRun the equivalent check for VPS-2 and VPS-3. The exact account name, hostname and authentication method are yours; do not copy credentials into shell history or scripts. Where supported by your MySQL release, dba.configureInstance() can apply compatible configuration changes instead of editing every setting manually. Review each proposed change before accepting it.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
4. Create the cluster in single-primary mode
From a clean, correctly configured VPS-1 connection, create the cluster with a unique name. The AdminAPI pattern is:
var cluster = dba.createCluster('prodCluster', {multiPrimary: false});Single-primary mode is the normal starting point. One member accepts writes, which limits concurrent write conflicts and keeps application behavior straightforward. A multi-primary group can allow writes on more than one member, but conflict handling, transaction certification failures and application retry logic become your responsibility.
5. Add the second and third members
Add VPS-2 and VPS-3 through AdminAPI rather than hand-editing every Group Replication setting:
cluster.addInstance('admin@vps-2.example:3306');
cluster.addInstance('admin@vps-3.example:3306');
cluster.status();AdminAPI may use MySQL Clone to provision a joining instance. Clone replaces the joining server’s data with a copy from a donor, so verify that the target contains no data you need to preserve and that the donor has enough disk, network and I/O capacity for the operation. For a large existing database, plan the cloning window and monitor disk space before starting.
Rank #3
- 【Advanced Home Data & Media Hub】For advanced home users who need phone backup, file storage, and centralized data management. Centralize family photos, 4K videos, movies, computer backups, and personal files in one place while running multiple apps for home entertainment and everyday data management. Suitable for households with growing digital libraries and multiple NAS use cases.
- 【Built for Creators, Media Servers & Advanced Apps】Powered by the Intel N100 Quad-Core CPU, 8GB DDR5 RAM, 2.5GbE networking, and dual M.2 NVMe slots, DXP2800 handles large files and heavier workloads with ease. Run Docker, virtual machines, and media server applications compatible with Plex—ideal for content creators, tech enthusiasts, and advanced home users managing 4K videos, RAW photos, personal media libraries, and multiple NAS apps.
- 【Up to 80TB for Growing Digital Libraries】 Supports up to 80TB of storage using two HDD bays and two M.2 NVMe SSD slots for family photos, movies, RAW photos, 4K videos, work files, and device backups. AI photo management supports recognition of people, objects, scenes, and locations, album organization, and duplicate photo detection. HDDs and SSDs are not included.
- 【AI-powered Home Surveillance】Turn DXP2800 into a centralized home surveillance hub by connecting compatible network cameras and storing recordings locally on your NAS. AI-powered features include Face Recognition, People Detection, and Pet Detection, helping advanced home users review important events more efficiently while managing home surveillance and personal data in one place.
- 【One data Center Across Your Devices】Keep files from desktops, laptops, phones, tablets, and other devices together instead of scattered across cloud accounts and external drives. Access, back up, organize, and share data across Windows, macOS, Android, iOS, web browsers, and compatible smart TVs—ideal for creators and advanced home users working across multiple devices.
6. Confirm membership and roles
Inspect cluster.status() and confirm that all three members are ONLINE. In single-primary mode, verify that exactly one member is the read/write primary and the other two are read-only secondaries. Investigate any member in a recovery, error or offline state before routing production traffic.
Check the transaction backlog and applier health after the initial synchronization. A node that is technically online but permanently behind is not a useful failover target.
7. Bootstrap MySQL Router
Install MySQL Router on a separate application-tier host or on hosts near the application instances. Bootstrap it against the cluster using the Router deployment workflow for your MySQL Shell version. Router stores cluster metadata, discovers the current primary and exposes endpoints for read/write and optional read-only traffic.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Fix the driver behind crashes, sound loss and screen glitches3Clear out junk files and repair common Windows errorsdba.deployRouter('router-app-1.example', {account: 'routeradmin'});The exact deployment command and account options vary by MySQL Shell release and operating-system packaging. Follow the prompts to create a dedicated Router account and choose listening ports. Do not reuse the full administrative account for application connections.
8. Change the application connection
Replace direct database hostnames in application configuration with the Router read/write endpoint. Configure a separate read-only endpoint only for code that can tolerate replica lag and read-after-write differences. Set connection timeouts and retry behavior in the application driver, and ensure the pool discards broken connections after a primary change.
Retain direct node addresses in a protected administration configuration. They are needed when Router itself is unavailable or when an operator must recover a member.
Choosing single-primary or multi-primary mode
| Decision factor | Single-primary | Multi-primary |
|---|---|---|
| Write conflicts | Writes converge through one primary, so conflict risk is lower. | Concurrent writes to the same rows or keys can conflict and be rejected by certification. |
| Application complexity | Usually fits existing single-writer applications with ordinary retry handling. | Requires conflict-aware transactions, retries and careful key or workload partitioning. |
| Failover behavior | The group elects another member as primary after a failure; Router redirects new connections. | Several members may accept writes, but conflict and ordering behavior must be tested by the application team. |
| Read scaling | Reads can use secondaries through Router when replica-read semantics are acceptable. | Writes may be distributed, but read scaling still depends on workload and replica capacity. |
| Operational burden | Lower and easier to reason about. | Higher; use it only when the workload has a documented reason for concurrent writers. |
Multi-primary is an advanced option, not a substitute for capacity planning. It does not remove quorum requirements or make a partition safe. Start with single-primary unless your application has been designed and tested for write conflicts.
Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallCrashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteRank #4
- Dell PowerEdge R730xd 24B SFF 2U Server
- 2x Intel Xeon E5-2690 v4 2.6Ghz 14-Core (28-cores Total)
- 128GB DDR4 RAM – 4x 1.2TB 10K SAS 2.5” 12Gb/s
- Dell H730P mini 2GB 12Gb/s RAID
- 2x 750W PSU - 2x 10Gb SFP+ 2x 1Gb (RJ45) NIC
Security hardening
Network and account controls
- Use private networking for member traffic and restrict TCP 33061 to the three member addresses.
- Allow SQL access only from application, Router and management networks that require it.
- Create separate accounts for AdminAPI, Router, monitoring, backups and applications. Grant each only the privileges it needs.
- Disable or restrict anonymous accounts and remote administrative logins, and store secrets in a protected secret manager rather than source code.
- Apply operating-system updates and MySQL security updates on a tested schedule. Keep versions compatible while rolling through an upgrade.
TLS for clients and members
Use TLS for client connections, recovery traffic and member communication where your security policy requires encryption in transit. MySQL Router supports verification modes including VERIFY_CA and VERIFY_IDENTITY. With identity verification, certificate names must match the hostnames or addresses that applications actually use. Plan certificate rotation before expiry and test a replacement certificate on a non-primary path.
Monitoring and operational runbooks
High availability is a continuously operated system, not just a successful cluster creation. Monitor:
- Group membership and each member’s state, including transitions out of
ONLINE. - Quorum availability and the number of reachable members.
- Applier errors, certification failures and transaction backlog.
- CPU, memory, storage latency, free disk space and network saturation on every VPS.
- Router metadata refresh, listener health and connection errors.
- TLS certificate expiration and failed identity validation.
- Private-network DNS resolution and bidirectional reachability.
- Backup completion, restore-test results and the age of the latest verified backup.
Write and rehearse a runbook for a planned primary switchover, an unplanned node loss, loss of quorum, Router failure and rejoining a rebuilt VPS. Group Replication detects membership changes, but it does not redirect existing application clients by itself. Router or another middleware layer must handle new connection routing, while the application must close and recreate connections that were attached to the failed primary.
Failover and recovery procedures to test
Planned primary switchover
- Confirm that all members are
ONLINEand synchronized. - Drain or pause write traffic according to the application’s maintenance procedure.
- Use the supported AdminAPI operation for your MySQL release to select another member as primary.
- Verify the new primary and Router metadata, then open a test write through the Router endpoint.
- Resume traffic and inspect application error rates and replication health.
Unplanned member loss
When one of three members fails, the remaining two can retain quorum. Check that Router sends new read/write connections to the elected primary, then investigate the failed VPS without repeatedly restarting healthy members. Existing client sessions can still hold dead sockets; application pools must reconnect.
Quorum loss
If two members are unavailable in a three-member group, the remaining member cannot make automatic progress. Do not force arbitrary writes without a documented recovery plan: doing so can create divergent histories. Restore network connectivity or recover enough members to regain a majority, then follow the cluster’s supported reconfiguration and recovery procedure.
Rejoining a rebuilt VPS
- Rebuild the operating system and install versions compatible with the surviving cluster.
- Recreate private DNS, firewall rules, TLS material and unique server identity.
- Run the instance configuration checks and remove any stale data that could conflict with cloning.
- Add the rebuilt instance with AdminAPI and monitor Clone or distributed recovery until it is
ONLINE. - Confirm that it is a healthy failover candidate before counting it toward your capacity plan.
Sizing the VPS instances
There is no universal VPS size or latency threshold that guarantees cluster performance. Size CPU, memory, storage IOPS, network bandwidth and connection capacity from workload measurements. Measure peak and sustained write rate, transaction size, concurrent sessions, buffer-pool needs, backup load and the time available for a node to recover.
Use equivalent or better capacity on all members when any member may become primary. A secondary with substantially slower storage can lengthen recovery and create backlog precisely when the cluster is under stress. Leave headroom for clone operations, binary logs, temporary tables, backups and operating-system activity.
Common failure modes and fixes
| Symptom | Likely cause | Corrective action |
|---|---|---|
| Member never joins | TCP 33061 blocked, wrong private address, DNS mismatch or certificate failure | Test both directions between every pair, compare resolved addresses, and check host and provider firewalls. |
| AdminAPI rejects configuration | Duplicate server_id, GTIDs disabled, inconsistent case settings or unsupported replication mode |
Run the instance check on the affected member, correct the reported values and restart when required. |
| Clone fails for lack of space | Target disk cannot hold the donor’s data and recovery files | Expand storage or clean the target, then repeat cloning only after verifying that no required data is on the target. |
| Router still sends traffic to a failed server | Router cannot refresh metadata or existing pools retain stale sockets | Check Router connectivity and metadata refresh, then recycle dead application connections. |
| Writes stop after a second outage | Three-member group lost its majority | Restore a second member or network path; follow the documented quorum-recovery process instead of forcing isolated writes. |
| Replica appears online but is behind | Storage, CPU or network saturation, or applier errors | Inspect backlog and applier status, correct the bottleneck, and do not use the member for failover until it catches up. |
Production readiness checklist
- Three independent VPS instances have stable private names and addresses.
- Every node uses InnoDB, a unique positive
server_id, GTIDs and consistent case and encryption settings. - TCP 33061 is reachable only between members; SQL and Router ports are limited to trusted networks.
- All members report
ONLINE, with one intended primary in single-primary mode. - Applications connect through Router, not directly to a member.
- TLS verification, account privileges, secret storage and certificate rotation are documented.
- Monitoring covers quorum, membership, backlog, resources, Router and backups.
- Failover, quorum loss, Router recovery, restore and rebuilt-node rejoin have been tested.
Final design recommendation
For most Linux VPS deployments, choose three MySQL Server instances in a private network, configure InnoDB and GTID-based Group Replication, create a single-primary InnoDB Cluster with MySQL Shell AdminAPI, and place MySQL Router between the cluster and applications. Treat 33061 as private member traffic, keep direct node access for operations, and validate failover and backups under controlled conditions before declaring the service highly available.
Recommended Free Tools
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
