Detach the Bottomless Database

Hi all,

I did PITR(Point-in-Time Recovery) performance test with Bottomless Database (in v.7.5.beta).
There was a problem detaching the database after checking its normal behavior.

I should have deleted the data files in S3 after I ran the DETACH command in SingleStore.
However, that command does not work in spite of using the force option, because I deleted the files in S3, first.

I deleted all the tables in the DB, stopped and restarted the entire node.
But, the Bottomless Database is now unable to command use.

Furthermore, some commands such as CREATE DATABASE and TRUNCATE were executed slowly or failed.

The current state of the cluster is as follows.
$ sdb-admin list-nodes
±-----------±-------±--------------±------±--------------±-------------±--------±---------------±-------------------±-------------+
| MemSQL ID | Role | Host | Port | Process State | Connectable? | Version | Recovery State | Availability Group | Bind Address |
±-----------±-------±--------------±------±--------------±-------------±--------±---------------±-------------------±-------------+
| 4E63264C4B | Master | 192.168.1.200 | 30130 | Running | True | 7.5.2 | RecoveryFailed | | 0.0.0.0 |
| 4D4A3D4152 | Leaf | 192.168.1.200 | 30131 | Running | True | 7.5.2 | RecoveryFailed | 1 | 0.0.0.0 |
| 58065EFDD6 | Leaf | 192.168.1.200 | 30132 | Running | True | 7.5.2 | RecoveryFailed | 2 | 0.0.0.0 |
±-----------±-------±--------------±------±--------------±-------------±--------±---------------±-------------------±-------------+

singlestore> show databases;
+--------------------+ 
| Database           |
+--------------------+
| cluster              |
| information_schema |
| memsql            |
| metrics             |	> Local Database
| mk_bottom       |	> Bottomless Database
+--------------------+

singlestore> use mk_bottom;
ERROR 1768 (HY000): The database 'mk_bottom' is corrupted and can't be recovered. Please contact technical support.

singlestore> CREATE DATABASE IF NOT EXISTS test;
Query OK, 1 row affected, 6 warnings (**8 min 1.15 sec**)

singlestore> create table t1 (a int, b int);
Query OK, 0 rows affected (0.02 sec)

singlestore> insert into t1 values(1,2);
Query OK, 1 row affected (0.03 sec)

singlestore> truncate t1;
ERROR 2282 (HY000): Failed to synchronize database. Timed out waiting for the ReplicationManagement thread to synchronize
  1. How can I forced detach the bottomless database in this case?

  2. Is the reason for the slow CREATE DATABASE command related to Bottomless Database?
    And How can I solved that?

Hi,

Can we see the error that DETACH … FORCE is giving you? That is the command that should drop the database no matter the state of S3. I’ve opened an internal investigation to try and reproduce this ourselves in the meantime.

Can you also create a cluster report (SingleStoreDB Cloud · SingleStore Documentation) and e-mail it to bug-report@memsql.com so we can take a deeper look at the logs.

-Adam

I’m sorry to late reply.

The current error seems to be different from when this inquiry was posted.

singlestore> DETACH DATABASE mk_bottom;
ERROR 1730 (HY000): The database 'mk_bottom' is in the 'unrecoverable' state and is thus not available for move to bottomless. Run SHOW DATABASES EXTENDED and visit https://docs.memsql.com/docs/database#database-states for more information

singlestore> SHOW DATABASES;
+--------------------+ 
| Database           |
+--------------------+
| cluster              |
| information_schema |
| memsql          |
| metrics           |	> Local Database
| mk_bottom	|	> Bottomless Database
| mk_test		|	> Bottomless Database
| test		|	> Local Database
| test2		|	> Local Database
+--------------------+

singlestore> SHOW DATABASES EXTENDED;
+--------------------+---------+--------+---------------+----------+---------+-------------+------------+-----------------+-------------------+------------------+----------------+------+--------------+--------------+-------------+---------------------+
| Database           | Commits | Role   | State         | Position | Details | AsyncSlaves | SyncSlaves | ConsensusSlaves | CommittedPosition | HardenedPosition | ReplayPosition | Term | LastPageTerm | Memory (MBs) | Pending IOs | Pending blob fsyncs |
+--------------------+---------+--------+---------------+----------+---------+-------------+------------+-----------------+-------------------+------------------+----------------+------+--------------+--------------+-------------+---------------------+
| cluster            |       0 | master | online        | 0:3393   |         |           2 | 0          |               0 | 0:3393            | 0:3393           | NULL           |    7 |            0 |         0.00 |           0 |                   0 |
| information_schema |       0 | master | online        | 0:1      |         |           0 | 0          |               0 | 0:1               | 0:1              | NULL           |    2 |            0 |         0.00 |           0 |                   0 |
| memsql             |       0 | master | online        | 0:579787 |         |           0 | 0          |               0 | 0:579787          | 0:579787         | NULL           |    7 |            0 |         0.00 |           0 |                   0 |
| metrics            |       0 | master | online        | 0:735    |         |           2 | 0          |               0 | 0:735             | 0:735            | NULL           |   94 |            0 |         0.13 |           0 |                   0 |
| mk_bottom          |       0 | master | unrecoverable | 0:1155   |         |           0 | 0          |               0 | 0:0               | 0:0              | NULL           |  846 |            0 |         0.00 |           0 |                   0 |
| mk_test            |       0 | master | unrecoverable | 0:2251   |         |           0 | 0          |               0 | 0:0               | 0:0              | NULL           |  917 |            0 |         0.00 |           0 |                   0 |
| test               |       0 | master | online        | 0:112    |         |           2 | 0          |               0 | 0:112             | 0:112            | NULL           | 1052 |            0 |         0.00 |           0 |                   0 |
| test2              |       0 | master | online        | 0:70     |         |           2 | 0          |               0 | 0:70              | 0:70             | NULL           | 1070 |            0 |         0.00 |           0 |                   0 |
+--------------------+---------+--------+---------------+----------+---------+-------------+------------+-----------------+-------------------+------------------+----------------+------+--------------+--------------+-------------+---------------------+
8 rows in set (0.00 sec)

I sent the report by e-mail. Please check.

Hi,

What about:

DETACH DATABASE mk_bottom FORCE;

Does this still give an error? The FORCE flag is suppose to allow detaching the database no matter its state.

I just tried Detach using the Force option and it was done normally!

singlestore> DETACH DATABASE mk_bottom FORCE;
Query OK, 0 rows affected, 8 warnings (6 min 2.56 sec)

I think it was because I tried to detach the database before all recovery attempts were completed.

Thanks!