0

This is My SQL Project instance log. I set the instance not to shut down automatically. But why does the instance automatically shut down irregularly?

2019-03-28 08:58:13.100 JST
2019-03-27 23:58:13 402333 [Note] : Normal shutdown
2019-03-28 08:58:13.100 JST
2019-03-27 23:58:13 402333 [Note] Giving 86 client threads a chance to die gracefully
2019-03-28 08:58:13.100 JST
2019-03-27 23:58:13 402333 [Note] Event Scheduler: Killing the scheduler thread, thread id 1
2019-03-28 08:58:13.100 JST
2019-03-27 23:58:13 402333 [Note] Event Scheduler: Waiting for the scheduler thread to reply
2019-03-28 08:58:13.100 JST
2019-03-27 23:58:13 402333 [Note] Event Scheduler: Stopped
2019-03-28 08:58:13.100 JST
2019-03-27 23:58:13 402333 [Note] Event Scheduler: Purging the queue. 8 events
2019-03-28 08:58:13.100 JST
2019-03-27 23:58:13 402333 [Note] Shutting down slave threads
2019-03-28 08:58:15.101 JST
2019-03-27 23:58:15 402333 [Note] Forcefully disconnecting 77 remaining clients
2019-03-28 08:59:15.029 JST
2019-03-27 23:59:15 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details).
2019-03-28 08:59:15.029 JST
2019-03-27 23:59:15 0 [Warning] Insecure configuration for --secure-file-priv: Current value does not restrict location of generated files. Consider setting it to a valid, non-empty path.
2019-03-28 08:59:15.029 JST
2019-03-27 23:59:15 0 [Note] (mysqld 5.6.39) starting as process 681358 ...
2019-03-28 08:59:15.135 JST
2019-03-27 23:59:15 681358 [Note] Semi-sync replication initialized for transactions.
2019-03-28 08:59:15.135 JST
2019-03-27 23:59:15 681358 [Note] Semi-sync replication enabled on the master.
2019-03-28 08:59:15.164 JST
2019-03-27 23:59:15 681358 [Note] InnoDB: Using atomics to ref count buffer pool pages
2019-03-28 08:59:15.164 JST
2019-03-27 23:59:15 681358 [Note] InnoDB: The InnoDB memory heap is disabled
2019-03-28 08:59:15.164 JST
2019-03-27 23:59:15 681358 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2019-03-28 08:59:15.164 JST
2019-03-27 23:59:15 681358 [Note] InnoDB: Memory barrier is not used
2019-03-28 08:59:15.164 JST
2019-03-27 23:59:15 681358 [Note] InnoDB: Compressed tables use zlib 1.2.11
2019-03-28 08:59:15.165 JST
2019-03-27 23:59:15 681358 [Note] InnoDB: Using CPU crc32 instructions
2019-03-28 08:59:15.169 JST
2019-03-27 23:59:15 681358 [Note] InnoDB: Initializing buffer pool, size = 384.0M
2019-03-28 08:59:15.194 JST
2019-03-27 23:59:15 681358 [Note] InnoDB: Completed initialization of buffer pool
2019-03-28 08:59:15.876 JST
2019-03-27 23:59:15 681358 [Note] InnoDB: Highest supported file format is Barracuda.
2019-03-28 08:59:16.055 JST
2019-03-27 23:59:16 681358 [Note] InnoDB: The log sequence numbers 15484232789 and 15484232789 in ibdata files do not match the log sequence number 15556766492 in the ib_logfiles!
2019-03-28 08:59:16.055 JST
2019-03-27 23:59:16 681358 [Note] InnoDB: Database was not shutdown normally!
2019-03-28 08:59:16.055 JST
2019-03-27 23:59:16 681358 [Note] InnoDB: Starting crash recovery.
2019-03-28 08:59:16.055 JST
2019-03-27 23:59:16 681358 [Note] InnoDB: Reading tablespace information from the .ibd files...
2019-03-28 08:59:18.420 JST
2019-03-27 23:59:18 681358 [Note] InnoDB: Restoring possible half-written data pages
2019-03-28 08:59:18.420 JST
2019-03-27 23:59:18 681358 [Note] InnoDB: from the doublewrite buffer...
2019-03-28 08:59:25.719 JST
2019-03-27 23:59:25 681358 [Note] InnoDB: 128 rollback segment(s) are active.
2019-03-28 08:59:25.722 JST
2019-03-27 23:59:25 681358 [Note] InnoDB: Waiting for purge to start
2019-03-28 08:59:25.773 JST
2019-03-27 23:59:25 681358 [Note] InnoDB: 5.6.39 started; log sequence number 15556766492
2019-03-28 08:59:25.804 JST
2019-03-28 08:59:27.036 JST
2019-03-27 23:59:27 681358 [Note] Event Scheduler: Loaded 8 events
2019-03-28 08:59:27.037 JST
2019-03-27 23:59:27 681358 [Note] : ready for connections.
2019-03-28 08:59:27.037 JST

Version: '5.6.39' socket: '' port: 0 (38, 40) (Google) 2019-03-28 08:59:27.038 JST 2019-03-27 23:59:27 681358 [Note] Event Scheduler: scheduler thread started with id 1

Is there a part in google-cloud-sql that sets the instance to shut down automatically?

  • Please give more information about your instance type. How manay memory you have? Chash might cause by outOfmemory – howie Mar 28 '19 at 2:01
  • D1 Instance 512MB MEMORY RAM. On average, 100 users connect at the same time a day. – 금융공학thinkpool Mar 28 '19 at 2:21
  • innodb buffer pool size = 4GB. max_connections = 1000. thread_cache_size = 3 – 금융공학thinkpool Mar 28 '19 at 2:22
  • 100 concurrent user ? check your system log . I thinks 512 mb mem is too low. – howie Mar 28 '19 at 2:28
  • It appears on the log that the schedule has been completed by the specified schedule. Is innodb_buffer_size or max_connection or thread_cashe_size okay? Is outofmemory the biggest problem? – 금융공학thinkpool Mar 28 '19 at 4:04
1

Are your instances 1st or 2nd generation? The activation policy configuration for 1st generation instances can cause your instance to automatically shut itself off after 15 minutes of inactivity.

Regarding your bottom-line question: yes, instances are set to automatically shutdown (both generations) for maintenance. For second generation instances, you can specify maintenance windows.

UPDATE

Your 1st Gen. instances may be shut down for maintenance at discretion. I recommend you to upgrade your instances to 2nd Generation.

  • @thinkpool With 77 remaining clients, during the shutdown, you were probably not in the 15 minutes of inactivity scenario to make you eligible for automatic shut off. – Wilson Hauck Mar 31 '19 at 0:57
  • You are using a first-generation instance. The memory RAM is 512mb. right. It was in a situation that shutdown could not be done because 71 users were connected. By the way, I do not know why I shutdown. – 금융공학thinkpool Apr 2 '19 at 7:58
  • I updated my answer. – alextru Apr 2 '19 at 11:54
0

InnoDB's buffer_pool lives in RAM. Setting its size to 4GB, but having only 0.5GB of RAM leads to a lot of swapping. Swapping is terrible for performance. Change innodb_buffer_pool_size to 100M.

Again, with such a small memory, you should not have `max_connections very high. Let's say 20, not 1000.

"100 users connect at the same time a day" -- I could interpret that two ways. Please check Threads_running and Max_used_connections (see SHOW GLOBAL STATUS)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.