For a good portion of today, SoylentNews was generating 503 errors if you either logged in or tried to post a comment. While not 100% consistent, the underlying problem is that the design of MySQL cluster requires us to manually allocate space for indexes and data storage. Today, the index storage maxed out, and MySQL refused to insert new rows stating "Table 'name' is full".
We've doubled the size of the IndexMemory which should solve this issue in the short term. Longer term, we need to migrate some data to reside permanently on HDD storage. If anyone has experience with MySQL Cluster and can offer suggestions, we're all ears.
Here's our current memory usage on the cluster for those who are interested:
ndb_mgm> all report memoryusage Node 2: Data usage is 81%(53650 32K pages of total 65536) Node 2: Index usage is 46%(15407 8K pages of total 32800) Node 3: Data usage is 81%(53648 32K pages of total 65536) Node 3: Index usage is 46%(15407 8K pages of total 32800)
Sorry for any inconvenience
(Score: 3, Informative) by NCommander on Saturday August 08 2015, @12:24AM
It's a long desired feature. I may put the time into making it happen much sooner than I expected. The odds are we'll migrate to PostgreSQL-XC which is a clustering variant; our experience is that we can't always be in control of restarts and such, and cluster technologies are much more resilient to a single node suddenly going down.
Still always moving
(Score: 3, Informative) by Post-Nihilist on Saturday August 08 2015, @12:37AM
have a look at https://github.com/postgres-x2/postgres-x2 [github.com] as PostgreSQL-XC seems dead. The last commit in PostgreSQL-XC is dated from 3 years ago
Be like us, be different, be a nihilist!!!
(Score: 2) by NCommander on Saturday August 08 2015, @01:11AM
Thanks. I'll keep this in mind.
Still always moving
(Score: 2) by KritonK on Monday August 10 2015, @08:02AM
According to the README [github.com] file, Postgres-X2 is Postgres-XC, renamed after it was moved to github. Internally, they still use the old name in various places, including the README file itself. (Check the "status" section.)
(Score: 2) by mendax on Saturday August 08 2015, @01:08AM
It's a good idea, but is the code base amenable to making that an relatively simple task? For example, in the Java world, as long as you're not doing anything terribly spooky or dependent upon a feature of a specific database, Hibernate makes switching DBMSes pretty straightforward (so long as you don't mind mediocre performance). However, I know next to nothing about Perl except that I tried learning it but had to keep forcing the vomit back down my throat.
It's really quite a simple choice: Life, Death, or Los Angeles.
(Score: 3, Informative) by NCommander on Saturday August 08 2015, @01:12AM
The database layer in rehash (the codebase that powers the site) is abstracted so changing database engines is possible, but its all handwritten SQL. aka, serious effort to change, but not impossible.
Still always moving
(Score: 2) by jdavidb on Saturday August 08 2015, @03:13AM
ⓋⒶ☮✝🕊 Secession is the right of all sentient beings