Skip to Content.
Sympa Menu

grouper-users - RE: [grouper-users] Maintaining Grouper database size

Subject: Grouper Users - Open Discussion List

List archive

RE: [grouper-users] Maintaining Grouper database size

Chronological Thread 
  • From: "Hyzer, Chris" <>
  • To: Shilen Patel <>, Rory Larson <>
  • Cc: "" <>
  • Subject: RE: [grouper-users] Maintaining Grouper database size
  • Date: Mon, 29 Jan 2018 19:03:27 +0000
  • Accept-language: en-US
  • Authentication-results: spf=none (sender IP is ) ;
  • Ironport-phdr: 9a23:6lA6AxfZHaC99ScRbafehup3lGMj4u6mDksu8pMizoh2WeGdxcWzZh7h7PlgxGXEQZ/co6odzbaO6ua4ASQp2tWoiDg6aptCVhsI2409vjcLJ4q7M3D9N+PgdCcgHc5PBxdP9nC/NlVJSo6lPwWB6nK94iQPFRrhKAF7Ovr6GpLIj8Swyuu+54Dfbx9HiTahfL9+Ngm6oRnMvcQKnIVuLbo8xAHUqXVSYeRWwm1oJVOXnxni48q74YBu/SdNtf8/7sBMSar1cbg2QrxeFzQmLns65Nb3uhnZTAuA/WUTX2MLmRdVGQfF7RX6XpDssivms+d2xSeXMdHqQb0yRD+v9LlgRgP2hygbNj456GDXhdJ2jKJHuxKquhhzz5fJbI2JKPZye6XQds4YS2VcRMZcTyxPDJ2hYYsTAeQPPuhYoIv8p1QSohWxChKhBP/0xTNUmnP6wbE23uYnHArb3AIgBdUOsHHModn7NqkTUeG0w7fSzTnbcvhbxzf96JLJchA6r/2HQLV9cc/NxkkvFwLEj0ufqZb+MjOUzeQCr3KX7/d4Ve2xjW4nrRt9rSayyccxk4TEgJ8exF7D9SV82ok1JNu4RVZ6Yd6iDJtfqTuaN41oTcM+XW1kojg1xaAbuZO9YSMEy4wnygbBZ/CacoWE+BzuWPiLLTtlh39pZKiziwux/ES80uHwS8e53EpQoidBj9XArG4B2wHX58SdV/dw/Eas1S6B1w/N6exIPUU5mK/fJpE83LI9l58evEbYESL5hkr7iaubelgq+uey7unqbbrrppGTOoJylwrwKL4hmtalDuQ9KgUOX3aU+eC71LD75UP0XLJEguErnqXArZ3UPcoWqre+AwBOzIkv8RG/Dyq60NsDmnkHMVRFdw+dg4jxIVHOJ+z4AumjjFSwkTdrwPbGMqfmApXQMnjDlLDhfbF+60JG1AUzytVf64pVCrEHPv3zRlf8uMLFAhI4KQC5zfjrBM9g2o4dRW6DGLKVPaDOvVOQ4+IgOeiMZIsbuDbnLPgl4ubjjXolll8dfaio3IUYaGqjE/RnOEWWfWDggsoZEWgUuAo+Svbmh0OfXj5Of3qyRb4z5iknCIK6CofOXo+tgKaG3CemBp1ZeHpGBkmREXfzaYqEQewMZTmWIs9giTwESaOhR5E72RGvsg/616RoLvDS+iIGqZLvysJ56PPOmhEvpnRICJGm02CJQmc8pmoUSjt+iLt/oEhwzH+PzKt1xfFUCIoXr8lOSBZyEZfG1Ot8Q4ToXgvbZdCPEX67RNHgDD0sGIEf2dgLNgxdCsevlFSL9CqwAqRf3+iOD5wl4K/G93nqLIBg03vA0u8sg0RwEZgHDnGvmqMqr1ubPIXOiUjM0v/yLak=
  • Spamdiagnosticmetadata: NSPM
  • Spamdiagnosticoutput: 1:99

Im worried about the future state of using direct SQL, maybe something else
in future will be needed that we put in the GSH command... you should
definitely use that.


-----Original Message-----

On Behalf Of Shilen Patel
Sent: Monday, January 29, 2018 1:34 PM
To: Rory Larson

Subject: Re: [grouper-users] Maintaining Grouper database size

If you’re going to trim the audit based on time, I’d suggest using the gsh
command since it’ll delete the records from the tables in the right order
(taking into account foreign keys). But as long as you delete them in the
right order via sql directly, that should be fine as well. Also, recently, I
documented how much space was being taken up at Duke (we use Oracle). I was
surprised to see so much of the space being used by indexes. We could
possibly look at reducing the number of indexes to help.

- Shilen

On 1/29/18, 9:13 AM,
on behalf of Rory Larson"
on behalf of


We are encountering an issue of our Grouper database growing to a size
that threatens to use up the entire hard drive space available. The database
server is a physical machine with no room to expand, running a MySQL-type
database (5.5.56-MariaDB MariaDB Server).

The problem is not so much the size of the group data itself, but with
point-in-time tables that record what that data was back to the beginning of
the Grouper installation. Some of these have grown to huge sizes, on the
order of 20 GB or so. A suggestion has been made that we could delete a lot
of this prior to some reasonable point in time, especially groups or
memberships that no longer exist. This would be fine, but I'm wondering if
this can be done from the database command line on a per-table basis, or
whether there are dependencies that require doing this through gsh function

Also, because this is a MySQL-type database, shrinking the database
physical size after deletion of unnecessary data is not trivial. OPTIMIZE
TABLE ... might work, or it might make a table bigger. ALTER TABLE ... ROW
FORMAT=COMPRESSED is promising as tried on our test database, but takes about
four times as long as OPTIMIZE TABLE. In either case, updating has to be
shut down while running them, and they may require duplicating the table
during the operation. We are at 90% now, and can't afford any more big
tables. The ultimate MySQL solution seems to be to dump the database, delete
the whole thing, and reload it, which would mean complete downtime for

Does anyone else using a MySQL-type database have a system for handling
this problem and maintaining a reasonable database size?


Archive powered by MHonArc 2.6.19.

Top of Page