Free tools Windows power users keep installed
One-click scans. No signup required.
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.
Build the cluster on a private network, start one RethinkDB node on TCP 29015, join the other VPS instances to that address, and then configure shards and replicas per table. For a production deployment, use at least three nodes, restrict 29015 to cluster members, restrict 28015 to application hosts, keep the 8080 administration interface private, and enable authentication and TLS whenever traffic crosses an untrusted network.
What you are building
A RethinkDB cluster is a group of independent server processes that discover one another over the intracluster port. The database distributes table shards across the machines and keeps replica copies according to each table’s configuration. A sharded table divides its keyspace so different nodes can serve different portions of the data; replication keeps additional copies available when a node or disk fails.
RethinkDB does not apply one global shard policy to every table. You choose the shard and replica counts when creating a table or change them later with reconfigure. After a topology change, rebalance moves data to the new shard layout. A table may have up to 64 shards, but that limit is not a recommendation for a particular workload.
Every shard has one authoritative primary replica. Additional replicas improve availability, but they do not eliminate the need to monitor which server is primary, whether primaries are concentrated on one failure domain, and whether failover can complete with the remaining nodes.
#1 Best Overall
- Powerful Turbo Fan:CAGIWIRU Electric Air Duster have reached speed up to 130000RPM,Can efficient remove dust and debris.With LED light and Three Adjustable Speed to meet with different cleaning tasks.
- With Attached USB C Fasting Charging cable.Charing 3 hours,Enjoy up to 240 minutes of use on the lowest setting, For third speed can use for 25mins.with four charging options to meet with your needs.
- Wide Application: attached 5 different nozzles,making it suitable for a variety of scenes, such as car,pet, pc, keyboards, and other electronic devices. It also serves for office and home clean duster.
- Handy Design & Portable:Cordless air duster electric nozzle is Light weight and small size, design and comfortable to hold and space saving, convenient to carry around. You can put it in your room or inside the car without taking up space.
- Economical &Reusable: Built durable materials with a long-lasting battery,our CAGIWIRU air duster it's a sustainable alternative to disposable air cans.
Prerequisites and a safe VPS topology
Use enough nodes for the failure you want to survive
Use three or more Linux VPS instances when the objective is to tolerate a node failure while keeping replicas available. With three nodes and three replicas, a table can normally retain a copy on each node, but the useful design depends on table size, write rate, disk performance, and the failure domains offered by your provider. Two VPS instances can form a cluster, yet they leave little room for a failure-tolerant majority and maintenance.
Place nodes on a private network
Put the VPS instances in the same private network, VPC, or equivalent security-group domain. A private address prevents database traffic from traversing the public internet and lets you write firewall rules that name the cluster rather than broad public ranges. If your provider offers multiple availability groups or regions, decide whether the extra network latency and transfer cost are justified by the failure isolation.
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Allow for stateful storage and operations
- Give each node persistent storage sized for its local primary and replica data, indexes, temporary space, and growth headroom.
- Use stable private addresses or provider DNS names so a replacement node can rejoin predictably.
- Synchronize system time and keep the same RethinkDB version and operating-system support level on all database nodes.
- Reserve capacity for rebalancing: moving shards consumes disk I/O, network bandwidth, and CPU while normal queries continue.
The official material does not publish a universal VPS size, price, throughput figure, or shard-count formula. Select a starting size from measured workload requirements, then test it with production-like data and traffic rather than treating a provider’s generic instance label as a RethinkDB guarantee.
Network ports and firewall rules
RethinkDB uses three default TCP ports. Separate their exposure so a compromised application host cannot automatically administer the cluster.
| Port | Purpose | Recommended source | Exposure |
|---|---|---|---|
| 29015 | Intracluster discovery and replication | Only the private addresses or security group containing RethinkDB nodes | Never expose publicly |
| 28015 | Driver connections from applications | Only trusted application hosts, bastions, or proxy nodes | Private; do not open to the internet |
| 8080 | HTTP administration interface | Administrators through a private network, SSH tunnel, or authenticated reverse proxy | Keep private |
The inbound rule for 29015 should use the cluster’s security group as its source when the provider supports that model. Rules should be stateful and limited to TCP; do not use an “allow all” rule simply because nodes need to communicate. If an application and database are on different private networks, route the private ranges explicitly and protect the connection with TLS.
Install and start the first RethinkDB node
Create a dedicated data directory
Install the RethinkDB package appropriate for your Linux distribution, create a directory on persistent storage, and give the service account ownership. Keep database files separate from the operating system volume so replacing a boot disk does not accidentally remove data. The exact package command varies by distribution; the cluster steps below are independent of that packaging choice.
Start a bootstrap node
The minimal documented pattern is:
rethinkdb --bind all
This listens on the default driver port 28015, cluster port 29015, and HTTP administration port 8080. The broad --bind all option is useful for a quick bootstrap or a lab, but it binds every interface. On a production VPS, replace it with explicit addresses:
--bind-clusterset to the node’s private address, so only the cluster network carries inter-node traffic.--bind-driverset to an address reachable by approved application hosts.--bind-httpset to localhost or a private administration address.
Choose a stable server name before the node joins the cluster. A name that changes after a rebuild makes logs and placement decisions harder to interpret. Confirm that the process is listening on the intended private address and that the local firewall permits the service before adding other machines.
Rank #2
- Screen Cleaner is Your Screen’s New Bestfriend! - EVEO is proud to present a screen cleaner that’s perfectly suited for your TV. Meet your new screen cleaner, computer screen cleaner, laptop cleaner, iPad cleaner, Macbook,tv cleaner or any other electronic device. Our screen cleaner spray and wipe along with the included plush microfiber cloth, easily removes dust, fingerprints & other smudges on the screen’s surface. Clean effectively for a streak-free screen
- Gentle on your Screens - Our screen cleaner spray and wipes is compatible to be used even for the most sensitive LCD, LED, CRT, and OLED screens in proper use. Be at ease knowing that this product is compatible with all the major brands: LG, SONY, Samsung, Sharp, iPad, iPhone, Android screens, Kindle, PC monitors - we’ve got you covered! Can be used as LCD screen cleaner, tv cleaner, smart tv screen cleaner, and more
- Premium Super Soft Plush Microfiber Cloth - Included in this efficient screen cleaning kit. This screen cleaner spray and wipe has our signature plush microfiber cloth specially designed to comply with screens and monitors and leave them streak-free. Has been shown to effectively absorbs stubborn stains, zero streaks, and no fiber shedding. Always use this together with our screen cleaner for the best results
- Easy-to-Use Screen Cleaner Kit + microfiber cleaning cloth - The EVEO Screen Cleaning Kit will easily be your new favorite tool when it comes to taking care of the things you love most, quick and easy solution for a streak-free screen. Simply screw on the sprayer gun on the screen cleaner bottle. Spray the cleaning liquid onto the microfiber cloth, then wipe the screen until desired cleanliness & shine is achieved.
- Quality Screen Care Kit Worth Purchasing - Enjoy a convenient Screen Cleaner anytime, anywhere you need it. Your satisfaction is our top priority. We stand behind the quality of our products and that’s why, you shouldn’t be worrying at all. We manufacture the Best Screen Cleaner. and can be used for laptop cleaning kit, laptop screen cleaner, tv screen cleaner for smart tv. MacBook screen cleaner, monitor cleaner or screen cleaner spray for electronic devices with microfiber cleaning cloth
Join the other VPS nodes
On each additional VPS, point --join at the first node’s private address and cluster port:
rethinkdb --join 10.0.0.10:29015 --bind all
Replace 10.0.0.10 with the bootstrap node’s private address. The join target is the intracluster port, not the driver port or the HTTP port. Once the second process starts, it becomes part of the same multi-machine cluster; repeat the operation for the third and subsequent nodes.
For production, combine --join with explicit private bindings and a stable server name. A node does not need to join every member: one reachable existing member is sufficient for discovery, although keeping more than one join address in operational documentation makes replacement easier if the first node is unavailable.
Persist settings in a configuration file
Command-line arguments are easy to mistype during a rebuild. Create one configuration file per node and keep it in configuration management. RethinkDB’s documented format is one key=value pair per line. Useful keys include server-name, repeated server-tag, join, canonical-address, cluster-port, driver-port, http-port, directory, and daemon.
A configuration file can look like this:
server-name=node-1
server-tag=default
server-tag=region_a
join=10.0.0.10:29015
cluster-port=29015
driver-port=28015
http-port=8080
directory=/var/lib/rethinkdb
# daemonUse a unique server-name on every VPS. Set canonical-address when a machine has multiple interfaces and you need RethinkDB to advertise a particular private address. The example’s daemon line is enabled by removing the comment marker when the process should detach; service managers commonly handle foreground execution instead, so use the convention supported by your distribution.
Before restarting a node with a new file, check that its data directory, private address, and join target are correct. Do not copy the first node’s file unchanged: duplicate names can make operator dashboards and placement rules ambiguous.
Recommended Free Tools
Choose shard and replica counts from measurements
What shards change
More shards can spread reads, writes, and storage across more machines, but they also create more coordination and metadata. Too few shards can leave CPU, disk, or network capacity stranded on a small number of servers. Too many shards can increase query fan-out and make rebalancing expensive. The documented maximum is 64 shards per table.
What replicas change
Replicas determine how many copies of each shard exist. A replica count of three requires enough eligible servers to place three copies; it is not useful to request more replicas than the topology can hold. More copies consume storage and write bandwidth but provide additional failover choices.
Rank #3
- 【Large size】：Measuring 800 x 300 mm/ 31. 5×12 inches, which is wider and taller than others. Large mouse pad can perfectly fit your keyboard and mouse of any size, and there is also ample space for peripherals such as phones, tablets, etc.
- 【LED backlight mouse pad】：Blade Hawks RGB mouse pad provides 7 static modes and 7 dynamic modes will give you the options you are looking for. Power-off memory function remembers the last lighting mode you selected. The super glow fiber Chroma will give you a colorful gaming setup that you want.
- 【Anti-slip rubber base】：Made from Natural rubber, this gaming mousepad will firmly grip your desktop, allowing you to enjoy the ultimate precision in the games you are most passionate about. It also comes with a texture that enhances this ability even further.
- 【Smooth and waterproof surface】: Micro-textured cloth surface, for extremely precise mouse control and a smooth movement. When liquid splashes on the gaming mouse pad, it forms water droplets and slides down. Will not delay your work or gameplay.
- 【Plug and play】: This mouse and keyboard pad is powered by USB, plug and play, no driver required. One button control light modes. Press one time to change the lighting mode, press twice to change the brightness, press and hold about 3 seconds turn ON/OFF.
Signals to collect before deciding
- Sustained and peak write rate, including burst duration.
- Read latency by query shape and the proportion of queries that touch multiple shards.
- Document size, index count, and expected storage growth.
- Disk IOPS and network transfer while normal traffic is running.
- How quickly a failed node must be replaced and how long a rebalance may run.
- Whether a failure domain can remove one entire region, availability group, or rack.
Use a staging cluster with production-like cardinality and indexes. Increase or decrease shard counts experimentally, record latency and resource use, then test a node failure and a full rebalance. Treat every numeric result as specific to your workload, VPS provider, date, and software version; the official documentation provides controls rather than a workload-independent sizing formula.
Create and reconfigure a sharded table
Create a new table
Specify initial shard and replica counts in the table-creation command:
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
r.db('app').tableCreate('events', {shards: 3, replicas: 3})This example requests three shards and three replicas for events; it is illustrative, not a universal recommendation. Ensure that at least three suitable servers are available and that their storage can hold the resulting copies.
Change an existing table
Use reconfigure when a table already exists:
r.db('app').table('events').reconfigure({shards: 3, replicas: 3})Changing these values starts a distribution change. Monitor server CPU, disk space, network traffic, query latency, and the progress of data movement. Schedule a large change during a period in which the workload has enough headroom.
Redistribute data
Run rebalance after changing the layout so shard data is redistributed:
r.db('app').table('events').rebalance()Do not assume that issuing reconfigure instantly produces an even physical distribution. Verify the resulting shard and replica status in the administration interface or through the system tables, and keep the desired configuration in a deployment script so a rebuilt table receives the same settings.
Use server tags to control replica placement
Server tags describe location or role. Start nodes with tags such as region_a and region_b, or update the running configuration through rethinkdb.server_config. Tags let a table’s configuration request replica counts for groups and identify a preferred primary-replica tag.
For example, you can place copies across two availability groups rather than allowing all replicas to land in one group. The exact tag-aware configuration must match the number of tagged servers and the failure policy you intend. If a tag has no eligible server, the requested placement cannot be satisfied.
Rank #4
- 【Softer and More Comfortable】Vaydeer wrist rest has unique diamond pattern, which is the combination of softness and aesthetics. The materials of wrist rest are improved into higher quality memory foam and covered with silky smooth lycra. The computer wrist rest makes you as comfortable and cushiony as like rest your wrists on clouds.
- 【Ergonomic Wrist Saver】The wrist rests for keyboard and mouse comes with a 17.32×3.15×0.83 inch keyboard wrist pad and a 5.94×3.15×0.83 inch mouse wrist support. Based on ergonomic design, the unique concave shape is the perfect fit for your wrist joints. The wrist rest pad fits most computer keyboards and laptops, improve hand and wrist posture, release your wrist and arm stress.
- 【Non-Slip Rubber Bottom】Featuring an anti-skid silicone base on the bottom, this wrist keyboard support stays firmly in place on your desk, preventing the padding from sliding around, ensuring stable and consistent wrist support during extended computer sessions.
- 【Better Experience & Pain Relief】Our keyboard arm rest is beneficial to alleviate the soreness caused by direct contact and friction between your arm and a hard desk surface, reducing the risk of wrist fatigue or carpal tunnel. The soft texture of memory foam can evenly distribute the pressure around your wrists and provide good support with just enough give.
- 【Helpful in Multiple Scenarios】Whether you're working, studying, writing, typing, gaming, this keyboard and mouse rest combo is an essential accessory to add comfort and support to your hands and wrists. It’s also a great gift for men, women, family, friend, coworker, gamer, teacher, etc.
Tags are not an automatic policy for future rebuilds. Save the desired table configuration, including tag assignments and the preferred primary tag, in a script or configuration repository. Reapply it after creating a table or changing the cluster’s server set.
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Secure the cluster before accepting application traffic
Bind each interface deliberately
Bind the cluster port only to a private address, the driver port only to approved application networks, and the HTTP interface only to an administrator’s private path. Never expose 28015 or 29015 to the public internet without a deliberate security design. A protected network that does not allow outside access is the strongest baseline for a cluster.
Set credentials and TLS
Configure an administrator password before giving anyone access to the web UI. The security guidance documents TLS for server-to-server traffic, client connections, and web-UI traffic. Enable the coverage required by your trust boundaries, distribute certificates securely, and verify hostname or address validation during a staged rollout. TLS protects traffic in transit; it does not replace firewall rules or least-privilege network access.
Provide controlled administration
When the UI must be reached from outside the private network, use an SSH tunnel or an authenticated reverse proxy rather than opening 8080 broadly. Log administrative access, rotate credentials according to your operations policy, and restrict tunnel endpoints to approved administrators. Keep database and operating-system logs available for detecting failed joins, authentication errors, and repeated connection attempts.
Consider proxy nodes for application access
A RethinkDB proxy stores no data. It routes application queries to the machines that hold the relevant shards and can be placed near the application tier. Start one by joining it to the cluster:
Do these 3 things before closing this tab:
1Fix the driver behind crashes, sound loss and screen glitches2Repair Windows errors before they cause bigger problems3Scan for outdated or missing drivers - takes under a minuterethinkdb proxy --join 10.0.0.10:29015
According to the official documentation, a proxy can reduce intercluster traffic, deduplicate changefeed messages, and perform some query processing on the application host, reducing database-server CPU. It is useful when many application processes would otherwise open direct connections to every data node. Because a proxy has no persistent table data, losing it does not lose a replica; deploy enough proxies for the application availability you require.
Compare practical deployment designs
| Design choice | Strength | Cost or risk | When it fits |
|---|---|---|---|
| All nodes in one provider region | Lower latency and simpler private networking | A regional outage can remove every replica | Applications whose recovery plan accepts regional risk |
| Nodes split across regions or availability groups | Better failure-domain isolation | Higher latency, transfer charges, and more complex routing | Systems that must survive loss of one location |
| Uniform replica counts | Simple table configuration and predictable storage use | May place primaries and copies in the same failure domain | Homogeneous nodes and a single-domain policy |
| Tag-aware placement | Explicit control of locations, roles, and primary preference | Requires maintained tags and enough eligible servers | Multi-zone or role-specific deployments |
| Direct driver connections | Fewer moving parts | Applications may create many cross-node connections | Small application fleets with controlled connection pools |
| Application-local proxy nodes | Can reduce cross-cluster traffic and duplicate changefeed delivery | Additional processes and proxy capacity to operate | Many clients or applications close to a proxy tier |
| Private network plus SSH tunnel or reverse proxy | Small administrative exposure | Requires tunnel or proxy operations | Teams that need occasional remote UI access |
| Private network plus TLS | Encrypts traffic across less-trusted links | Certificate issuance, rotation, and validation | Nodes or clients that cross a trust boundary |
Set write acknowledgement and durability intentionally
RethinkDB’s default write acknowledgement mode is majority. It waits for a majority of relevant replicas, providing stronger failure tolerance than acknowledging after a single server. The single mode can acknowledge faster, but a failure immediately after acknowledgement can lose the write if the only acknowledged copy is lost.
Durability is a separate choice. hard durability commits data to disk before acknowledgement; soft durability acknowledges sooner with less resilience to an abrupt process or machine failure. Select acknowledgement and durability per workload, document the decision, and test the actual failure window rather than assuming that replication alone defines durability.
Best Value
- 【No Drill Mounted】Cable management tray can be assembled in as little as 3 minutes or less-simply. Side clips easily clampe the edge of desk, pass through the holes on the sides, and secure excess cables with baskets. Desk cable management supports inward or outward installation to meet your needs in different scenarios, and provides you with great convenience when collecting and organizing wires.
- 【Rubber Pad Protects Desk】Wire organizer under desk built-in soft rubber pads on the clamp protect your desk from scratches, so you will not damage your furniture or office.
- 【Sturdy and Beautiful】Cord management under desk is made of high-quality carbon steel and holds about 15 lbs. The wire basket has 2 holes on each side of the tray to enable your cables to pass freely. Cable baskets are suitable for desk thickness use from 0.4" to 2.4".
- 【Space Saving & Keep Organized】Desk cable management tray holds all your power cords, outlet strips, USB hubs and computer transformers hidden from your feet, and the data cables will not enter the vacuum cleaner to keep your desk clean and tidy. Desk wire organizer is also suitable for use in the kitchen and outdoors.
- 【Reduce Safety Risks】Cable tray under desk keeps all plugs away from your kids, no more worry about tripping. Using 2 holes wire tray saves extra space, helps you easily cabling and wire protection. The mesh design is not easy to accumulate dust, but avoids safety accidents caused by messy wires.
Validate the cluster before production
- Confirm that every database node has a unique server name, the expected private address, and the same intended version.
- From each node, verify that TCP 29015 reaches the other database nodes and that no public interface accepts it.
- From an approved application host, verify driver access on 28015; from an unapproved host, verify that the firewall rejects it.
- Open the administration interface only through its private path, tunnel, or authenticated proxy, then confirm the administrator password works.
- Create a test table with the planned shard and replica counts and inspect where primaries and replicas are placed.
- Insert and read representative documents, including queries that target one shard and queries that fan out.
- Stop one node in staging. Confirm the expected failover behavior, write acknowledgement result, application reconnect logic, and changefeed handling.
- Restore the node, run the required reconfiguration or rebalance operation, and measure how long the cluster returns to the desired distribution.
- Record disk, CPU, memory, network, query latency, and replication symptoms during both normal traffic and recovery.
Troubleshoot common failures
A node will not join
Check that the join address is the existing node’s private address and port 29015, not 28015 or 8080. Confirm the security-group source, host firewall, route table, and process binding. If the node advertises an unreachable address, set canonical-address and restart with the intended private bindings. Review logs on both sides for refused connections or incompatible configuration.
Crashes, 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 minuteWindows 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 reinstallThe cluster shows an unhealthy replica layout
Compare the requested replica count with the number of eligible servers and their tags. A tag-aware policy cannot place a copy where no tagged server exists. Check whether a server is offline, out of disk space, or isolated by a firewall. Do not raise replica counts until the current placement and storage capacity are understood.
Queries become slow after adding shards
Determine whether the query touches one shard or fans out to many. Inspect CPU, disk latency, network transfer, and index coverage on every participating server. More shards do not automatically make an unselective query faster; reduce unnecessary fan-out, verify indexes, and compare with a measured staging workload before changing the layout again.
Rebalance threatens normal traffic
Check free disk space and network headroom, then schedule the operation during a lower-traffic window or reduce concurrent workload if your change plan permits. Monitor progress rather than repeatedly issuing commands. If the cluster cannot sustain the movement, stop making additional topology changes, preserve the current configuration, and expand capacity or revise the target shard count after testing.
The administration UI is unreachable
Verify that --bind-http or http-port points to the address you are actually using. If it is intentionally private, connect through the approved tunnel or reverse proxy instead of opening 8080 to the internet. Check the local firewall and service status without changing the cluster port rules.
Operate replacements and future changes safely
Keep the node configuration, table-creation and reconfiguration scripts, firewall rules, certificate process, and recovery runbook together. When replacing a VPS, provision its private networking and storage first, assign a new stable server name, apply its tags, and join it through 29015. Verify that it has become an eligible replica host before removing the failed server from the placement plan.
Change one major variable at a time: node count, shard count, replica policy, tags, or failure-domain placement. Capture baseline latency and resource measurements, perform the change in staging, and test failover before production. Because table settings are applied at creation or reconfigure time, a rebuild will not automatically remember the policy unless your automation does.
Production checklist
- Three or more Linux VPS nodes for a failure-tolerant starting topology.
- Private networking with TCP 29015 limited to database nodes.
- TCP 28015 limited to trusted applications or proxies.
- TCP 8080 private or reachable only through an authenticated tunnel or reverse proxy.
- Unique server names, explicit private bindings, persistent data directories, and configuration files under version control.
- Measured shard and replica counts, never an untested universal number.
- Server tags and a saved placement script when replicas must cross locations or roles.
- Administrator credentials, required TLS coverage, certificate rotation, and monitored logs.
- Documented acknowledgement and durability settings, including the behavior expected during node loss.
- Staging tests for workload performance, failure, recovery, and rebalance duration.
With those controls in place, the cluster’s mechanics are straightforward: bootstrap one private node, join the others on 29015, configure each table’s shards and replicas, rebalance deliberately, and continuously test the failure behavior your VPS topology is meant to withstand.
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.
The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →
