Why is an instance forced to reboot?MySQL InnoDB logfiles resized - review mysql-err.log for potential problemsMysql trying to recover from Hard disk failuremysql no longer defaulting to /tmp/mysql.sockMysql Server Crashing RegularlyMySql replication from 5.1 master to 5.6 slave keep crashingMYSQL 5.6 : Database Loss After Several Power OutttageMariaDB service won't start (mysqld.sock not found)Vanilla installation of MySQL on Windows 10 fails, service cannot start, corrupt InnoDB pageInnoDB ibdata1 corrupted, innodb_force_recover not workingInnodb cluster setup error
Map a function that takes arguments in different levels of a list
Calculus Books, preferably Soviet.
Updating multiple vector points at once with vertex editor in QGIS?
Some questions about Lightning and Tor
'Hard work never hurt anyone' Why not 'hurts'?
Which is the best password hashing algorithm in .NET Core?
To which country did MiGs in Top Gun belong?
garage light with two hots and one neutral
What is the maximal acceptable delay between pilot's input and flight control surface actuation?
LM317 to step voltage up
What is a "fat pointer" in Rust?
Declaring 2 (or even multi-) dimensional std::arrays elegantly
Why not use futuristic pavise ballistic shields for protection?
Why are Latin and Sanskrit called dead languages?
Ideal characterization of almost convergence
How did Gollum know Sauron was gathering the Haradrim to make war?
In mathematics is there a substitution that is "different" from Vieta's substitution to solve the cubic equation?
Why did the VIC-II and SID use 6 µm technology in the era of 3 µm and 1.5 µm?
Does secure hashing imply secure symmetric encryption?
A question about dihedral group
Initializing a std::array with a constant value
How to run a command 1 out of N times in Bash
Punishment in pacifist society
My boss says "This will help us better view the utilization of your services." Does this mean my job is ending in this organisation?
Why is an instance forced to reboot?
MySQL InnoDB logfiles resized - review mysql-err.log for potential problemsMysql trying to recover from Hard disk failuremysql no longer defaulting to /tmp/mysql.sockMysql Server Crashing RegularlyMySql replication from 5.1 master to 5.6 slave keep crashingMYSQL 5.6 : Database Loss After Several Power OutttageMariaDB service won't start (mysqld.sock not found)Vanilla installation of MySQL on Windows 10 fails, service cannot start, corrupt InnoDB pageInnoDB ibdata1 corrupted, innodb_force_recover not workingInnodb cluster setup error
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty margin-bottom: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?
mysql google-cloud-platform google-cloud-sql
asked Mar 28 at 1:42
금융공학thinkpool금융공학thinkpool
1
migrated from stackoverflow.com Mar 28 at 11:12
This question came from our site for professional and enthusiast programmers.
|
show 3 more comments
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?
mysql google-cloud-platform google-cloud-sql
asked Mar 28 at 1:42
금융공학thinkpool금융공학thinkpool
1
migrated from stackoverflow.com Mar 28 at 11:12
This question came from our site for professional and enthusiast programmers.
Please give more information about your instance type. How manay memory you have? Chash might cause by outOfmemory
– howie
Mar 28 at 2:01
D1 Instance 512MB MEMORY RAM. On average, 100 users connect at the same time a day.
– 금융공학thinkpool
Mar 28 at 2:21
innodb buffer pool size = 4GB. max_connections = 1000. thread_cache_size = 3
– 금융공학thinkpool
Mar 28 at 2:22
100 concurrent user ? check your system log . I thinks 512 mb mem is too low.
– howie
Mar 28 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 at 4:04
|
show 3 more comments
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?
mysql google-cloud-platform google-cloud-sql
asked Mar 28 at 1:42
금융공학thinkpool금융공학thinkpool
1
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?
mysql google-cloud-platform google-cloud-sql
mysql google-cloud-platform google-cloud-sql
asked Mar 28 at 1:42
금융공학thinkpool금융공학thinkpool
1
asked Mar 28 at 1:42
금융공학thinkpool금융공학thinkpool
1
asked Mar 28 at 1:42
금융공학thinkpool금융공학thinkpool
1
asked Mar 28 at 1:42
금융공학thinkpool금융공학thinkpool
1
asked Mar 28 at 1:42
금융공학thinkpool금융공학thinkpool
1
1
migrated from stackoverflow.com Mar 28 at 11:12
This question came from our site for professional and enthusiast programmers.
migrated from stackoverflow.com Mar 28 at 11:12
This question came from our site for professional and enthusiast programmers.
migrated from stackoverflow.com Mar 28 at 11:12
This question came from our site for professional and enthusiast programmers.
Please give more information about your instance type. How manay memory you have? Chash might cause by outOfmemory
– howie
Mar 28 at 2:01
D1 Instance 512MB MEMORY RAM. On average, 100 users connect at the same time a day.
– 금융공학thinkpool
Mar 28 at 2:21
innodb buffer pool size = 4GB. max_connections = 1000. thread_cache_size = 3
– 금융공학thinkpool
Mar 28 at 2:22
100 concurrent user ? check your system log . I thinks 512 mb mem is too low.
– howie
Mar 28 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 at 4:04
|
show 3 more comments
Please give more information about your instance type. How manay memory you have? Chash might cause by outOfmemory
– howie
Mar 28 at 2:01
D1 Instance 512MB MEMORY RAM. On average, 100 users connect at the same time a day.
– 금융공학thinkpool
Mar 28 at 2:21
innodb buffer pool size = 4GB. max_connections = 1000. thread_cache_size = 3
– 금융공학thinkpool
Mar 28 at 2:22
100 concurrent user ? check your system log . I thinks 512 mb mem is too low.
– howie
Mar 28 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 at 4:04
Please give more information about your instance type. How manay memory you have? Chash might cause by outOfmemory
– howie
Mar 28 at 2:01
Please give more information about your instance type. How manay memory you have? Chash might cause by outOfmemory
– howie
Mar 28 at 2:01
D1 Instance 512MB MEMORY RAM. On average, 100 users connect at the same time a day.
– 금융공학thinkpool
Mar 28 at 2:21
D1 Instance 512MB MEMORY RAM. On average, 100 users connect at the same time a day.
– 금융공학thinkpool
Mar 28 at 2:21
innodb buffer pool size = 4GB. max_connections = 1000. thread_cache_size = 3
– 금융공학thinkpool
Mar 28 at 2:22
innodb buffer pool size = 4GB. max_connections = 1000. thread_cache_size = 3
– 금융공학thinkpool
Mar 28 at 2:22
100 concurrent user ? check your system log . I thinks 512 mb mem is too low.
– howie
Mar 28 at 2:28
100 concurrent user ? check your system log . I thinks 512 mb mem is too low.
– howie
Mar 28 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 at 4:04
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 at 4:04
|
show 3 more comments
2 Answers
2
active
oldest
votes
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.
answered Mar 29 at 15:41
alextrualextru
113 bronze badges
@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 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 at 7:58
I updated my answer.
– alextru
Apr 2 at 11:54
add a comment |
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)
answered Apr 18 at 5:04
Rick JamesRick James
47.1k2 gold badges25 silver badges67 bronze badges
add a comment |
Your Answer
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "182"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fdba.stackexchange.com%2fquestions%2f233364%2fwhy-is-an-instance-forced-to-reboot%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
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.
answered Mar 29 at 15:41
alextrualextru
113 bronze badges
@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 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 at 7:58
I updated my answer.
– alextru
Apr 2 at 11:54
add a comment |
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.
answered Mar 29 at 15:41
alextrualextru
113 bronze badges
@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 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 at 7:58
I updated my answer.
– alextru
Apr 2 at 11:54
add a comment |
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.
answered Mar 29 at 15:41
alextrualextru
113 bronze badges
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.
answered Mar 29 at 15:41
alextrualextru
113 bronze badges
edited Apr 2 at 11:53
answered Mar 29 at 15:41
alextrualextru
113 bronze badges
answered Mar 29 at 15:41
alextrualextru
113 bronze badges
answered Mar 29 at 15:41
alextrualextru
113 bronze badges
113 bronze badges
@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 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 at 7:58
I updated my answer.
– alextru
Apr 2 at 11:54
add a comment |
@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 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 at 7:58
I updated my answer.
– alextru
Apr 2 at 11:54
@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 at 0:57
@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 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 at 7:58
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 at 7:58
I updated my answer.
– alextru
Apr 2 at 11:54
I updated my answer.
– alextru
Apr 2 at 11:54
add a comment |
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)
answered Apr 18 at 5:04
Rick JamesRick James
47.1k2 gold badges25 silver badges67 bronze badges
add a comment |
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)
answered Apr 18 at 5:04
Rick JamesRick James
47.1k2 gold badges25 silver badges67 bronze badges
add a comment |
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)
answered Apr 18 at 5:04
Rick JamesRick James
47.1k2 gold badges25 silver badges67 bronze badges
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)
answered Apr 18 at 5:04
Rick JamesRick James
47.1k2 gold badges25 silver badges67 bronze badges
answered Apr 18 at 5:04
Rick JamesRick James
47.1k2 gold badges25 silver badges67 bronze badges
answered Apr 18 at 5:04
Rick JamesRick James
47.1k2 gold badges25 silver badges67 bronze badges
answered Apr 18 at 5:04
Rick JamesRick James
47.1k2 gold badges25 silver badges67 bronze badges
47.1k2 gold badges25 silver badges67 bronze badges
add a comment |
add a comment |
Thanks for contributing an answer to Database Administrators Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fdba.stackexchange.com%2fquestions%2f233364%2fwhy-is-an-instance-forced-to-reboot%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Please give more information about your instance type. How manay memory you have? Chash might cause by outOfmemory
– howie
Mar 28 at 2:01
D1 Instance 512MB MEMORY RAM. On average, 100 users connect at the same time a day.
– 금융공학thinkpool
Mar 28 at 2:21
innodb buffer pool size = 4GB. max_connections = 1000. thread_cache_size = 3
– 금융공학thinkpool
Mar 28 at 2:22
100 concurrent user ? check your system log . I thinks 512 mb mem is too low.
– howie
Mar 28 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 at 4:04