[MCOL-543] AMI postConfigure creates additional instance with non-matching local EBS volume Created: 2017-02-05  Updated: 2019-07-10  Resolved: 2019-07-10

Status: Closed
Project: MariaDB ColumnStore
Component/s: installation
Affects Version/s: 1.0.7
Fix Version/s: Icebox

Type: Bug Priority: Major
Reporter: Daniel Lee (Inactive) Assignee: Unassigned
Resolution: Not a Bug Votes: 0
Labels: None


 Description   

Build tested: 1.0.7-1 AMI (binary), non-root user (mariadb-user)

I created an instance with 1TB local disk and use it to setup a 2UM combo stack. 1TB cpimport failed because PM2 ran out of disk space. It turned out that the local disk for PM2 is only 100GB.

PM1
[mariadb-user@ip-172-30-0-236 tests]$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/xvda2 1000G 99G 902G 10% /
devtmpfs 120G 0 120G 0% /dev
tmpfs 120G 16M 120G 1% /dev/shm
tmpfs 120G 17M 120G 1% /run
tmpfs 120G 0 120G 0% /sys/fs/cgroup
tmpfs 24G 0 24G 0% /run/user/1002
/dev/xvdz1 2.0T 1.1T 918G 55% /data

/dev/xvdz1 is an EBS volume where my 1TB source is.

PM2
[mariadb-user@ip-172-30-0-147 ~]$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/xvda2 100G 98G 2.3G 98% /
devtmpfs 120G 0 120G 0% /dev
tmpfs 120G 11M 120G 1% /dev/shm
tmpfs 120G 17M 120G 1% /run
tmpfs 120G 0 120G 0% /sys/fs/cgroup
tmpfs 24G 0 24G 0% /run/user/1002
[mariadb-user@ip-172-30-0-147 ~]$



 Comments   
Comment by David Hill (Inactive) [ 2017-02-06 ]

So the current way that ColumnStore does it is to create an instance based on the AMI which has the root size set to 100 gb. It's not based off the current size of the disk on pm1, which was increased when the AMI was launched.

But it looks like there is a way to do this:

1. would need to read the current size of the local disk, then use it when launching new instances.
2. how to launch new instances with large root disk:
http://blog.xi-group.com/2014/06/small-tip-use-aws-cli-to-create-instances-with-bigger-root-partitions/

Work-around for now is to use external EBS storage for DBROOT's

Generated at Thu Feb 08 02:21:52 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.