[
https://issues.apache.org/jira/browse/CASSANDRA-2749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylvain Lebresne updated CASSANDRA-2749:
----------------------------------------
Attachment: 0003-Fixes.patch
0002-fix-unit-tests.patch
0001-2749.patch
Attaching rebased patches, with a 3rd patches (0003-Fixes.patch) addressing the
Pavel's remarks. More specifically:
bq. o.a.c.db.Directories comment should be updated because it still uses
SSTable file name without keyspace.
Fixed, thanks
bq. o.a.c.io.sstable.SSTableReaderTest won't compile
Sorry, I forgot to check the test after a last rebase, fixed too (this involved
renaming a number of sstables from test/data/legacy-sstables/hb to include the
keyspace name, so that specific change is in the 2nd 'fix unit tests' patch to
avoid polluting the 3rd one).
bq. if you start with empty data directory you get following exception and
process exits
Fixed. I've actually made two modifications: the migration checks the existence
of the directory to avoid the NPE during listFiles(), but I've also modified
the 'should we migrate' check to detect new nodes (checking if the system
keyspace directory exists) and thus not print the migration message at all.
bq. on snapshot doesn't create or move (from older schema) index SSTables
related to CF
I'm not sure I see what this one is. Are we talking of the migration process?
In any case, you made me think about secondary indexes. Maybe it is more
"natural" to have secondary indexes sstables be in the same directory than the
base cfs? Since the indexes name is not really something exposed (granted you
don't have to be a genius to figure it out), it feels like it would slightly
simplify administration to not put them in a separate directory.
I've updated the patch to implement this last idea (so indexes are in the same
directory than their base cf), but it would be nice to have multiple opinions
on that move since we don't want to have to do a new migration in 6 month
because "we've changed our mind".
bq. shouldn't old "snapshots" directory be removed after move?
Your right, fixed (for backups too).
> fine-grained control over data directories
> ------------------------------------------
>
> Key: CASSANDRA-2749
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2749
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Jonathan Ellis
> Priority: Minor
> Fix For: 1.1
>
> Attachments: 0001-2749.patch,
> 0001-Make-it-possible-to-put-column-families-in-subdirect.patch,
> 0001-non-backwards-compatible-patch-for-2749-putting-cfs-.patch.gz,
> 0002-fix-unit-tests.patch, 0003-Fixes.patch, 2749.tar.gz,
> 2749_backwards_compatible_v1.patch, 2749_backwards_compatible_v2.patch,
> 2749_backwards_compatible_v3.patch, 2749_backwards_compatible_v4.patch,
> 2749_backwards_compatible_v4_rebase1.patch, 2749_not_backwards.tar.gz,
> 2749_proper.tar.gz
>
>
> Currently Cassandra supports multiple data directories but no way to control
> what sstables are placed where. Particularly for systems with mixed SSDs and
> rotational disks, it would be nice to pin frequently accessed columnfamilies
> to the SSDs.
> Postgresql does this with tablespaces
> (http://www.postgresql.org/docs/9.0/static/manage-ag-tablespaces.html) but we
> should probably avoid using that name because of confusing similarity to
> "keyspaces."
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
