Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

schema_rename_replacement in RESTORE SNAPSHOT not working as expected with partitioned table #15980

Closed
hlcianfagna opened this issue May 10, 2024 · 2 comments · Fixed by #16001
Assignees
Labels
bug Clear identification of incorrect behaviour

Comments

@hlcianfagna
Copy link
Contributor

CrateDB version

5.7.1

CrateDB setup information

See repro steps

Problem description

According to https://community.cratedb.com/t/restore-snapshot-into-new-table-name/167/4 it should be possible to restore a table from a snapshot using a different name however there seems to be an issue with partitioned tables, see below.

Steps to Reproduce

mkdir cratesnapshots
podman run -d --name cratetest --publish 4200:4200 --publish 5432:5432 -v /$(pwd)/cratesnapshots:/cratesnapshots --env CRATE_HEAP_SIZE=1g docker.io/crate/crate:5.7.1 -Cdiscovery.type=single-node -Cpath.repo=/cratesnapshots
podman exec -it cratetest "/bin/bash"
chmod o+rw /cratesnapshots
exit
crash
create repository mysnapdata type fs with (location='/cratesnapshots');
CREATE TABLE myschema.table1 (part_key int,anotherfield text) PARTITIONED BY (part_key);
INSERT INTO myschema.table1 (part_key,anotherfield) VALUES 
	(1,'first value on partition 1')
	,(2,'first value on partition 2');
refresh table myschema.table1;
create snapshot mysnapdata.snapshot1 all with (wait_for_completion=true);
update myschema.table1 set anotherfield='new value';
refresh table myschema.table1;
select * from myschema.table1;
/*
+----------+--------------+
| part_key | anotherfield |
+----------+--------------+
|        1 | new value    |
|        2 | new value    |
+----------+--------------+
*/	
RESTORE SNAPSHOT mysnapdata.snapshot1 TABLE myschema.table1 partition (part_key = 2) with (schema_rename_replacement = 'newschema', table_rename_replacement = 'mytable', wait_for_completion=true);

Actual Result

SELECT table_name, table_schema FROM information_schema.tables where table_schema in ('myschema','newschema');
/*
+------------+--------------+
| table_name | table_schema |
+------------+--------------+
| mytable    | newschema    |
| table1     | myschema     |
+------------+--------------+
*/
select * from myschema.table1;
/*
+----------+----------------------------+
| part_key | anotherfield               |
+----------+----------------------------+
|        1 | new value                  |
|        2 | new value                  |
|        2 | first value on partition 2 |
+----------+----------------------------+
--> the restore happened against the original table
*/
select * from newschema.mytable;
/*
+----------+--------------+
| part_key | anotherfield |
+----------+--------------+
+----------+--------------+
--> but the new table got created empty
*/

Expected Result

The restore happens against newschema.mytable and myschema.table1 is left untouched.

@hlcianfagna hlcianfagna added the triage An issue that needs to be triaged by a maintainer label May 10, 2024
@BaurzhanSakhariev BaurzhanSakhariev self-assigned this May 13, 2024
@BaurzhanSakhariev BaurzhanSakhariev added bug Clear identification of incorrect behaviour and removed triage An issue that needs to be triaged by a maintainer labels May 13, 2024
@BaurzhanSakhariev
Copy link
Contributor

Hi @hlcianfagna, thanks for reporting.

This issue is specific to restoring partitioned tables in general (not only specific partition but the whole table restoring has the same problem)

@BaurzhanSakhariev
Copy link
Contributor

Thanks for reporting, fix will be available in the 5.7.2 hotfix release.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Clear identification of incorrect behaviour
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants