3 ms·

can you do this (on a large table) without adding significant IO load/clogging up replication for an extended period of time?

• lazide 3y ago
  It’s worth noting that if your DB instance is so heavily loaded that this is a real concern, you already have a huge problem that needs fixing.
  • mschuster91 3y ago
    AWS is particularly bad with their performance credit system on RDS... and there's to my knowledge no way to tell MySQL to limit index creation IOPS, which means in the worst case you're stuck with a system swamped under load for days and constantly running into IO starvation, if you forget to scale up your cluster beforehand. Even if the cluster is scaled to easily take on your normal workload, indexing may prove to be too much for IO burst credits
    • lazide 3y ago
      That does seem like a real problem! Adding indexes periodically is a pretty regular thing for any production system where I come from.
    • nightpool 3y ago
      I have never had any problems with CONCURRENT index creations under significant load using Postgres, fwiw
    • grogers 3y ago
      You can use gh-ost (or most other online schema change tools) to get around that. You'll still have some necessary increase in write load since you are double-writing that table but you can control the pacing of the data backfill (gh-ost gives even more control as it doesn't use triggers to duplicate writes). It's not quite as simple as just running ALTER TABLE on the master though.
  • pornel 3y ago
    It may be so loaded from all the full table scans it's doing.