You are designing an application that will subscribe to and receive messages from a single Pub/Sub topic and insert corresponding rows into a database. Your application runs on Linux and leverages preemptible virtual machines to reduce costs. You need to create a shutdown script that will initiate a graceful shutdown.
What should you do?
To handle the preemption notice and initiate a graceful shutdown, you should write a shutdown script that uses inter-process signals to notify the application process to disconnect from the database. This method allows the application to respond directly to the signal, complete any in-progress tasks, and disconnect from the database, ensuring data is not lost or corrupted. Inter-process signals are a reliable and efficient mechanism for communicating between processes in Unix-like systems, which is essential for managing preemptible virtual machines.
IMO it should be A
I vote A
It's A To handle the preemption notice and initiate a graceful shutdown, you should write a shutdown script that uses inter-process signals to notify the application process to disconnect from the database. The application can then initiate a graceful shutdown by completing any in-progress tasks and disconnecting from the database, ensuring that data is not lost or corrupted during the shutdown process. This is the most reliable method for initiating a graceful shutdown in response to a preemption notice, as it allows the application to respond directly to the signal and initiate the shutdown process.
Option B, broadcasting a message to signed-in users and instructing them to save current work and sign out, is not relevant to the shutdown process of the application. Option C, writing a file in a location that is being polled by the application, is not a reliable method for initiating a graceful shutdown because the application may not read the file in a timely manner. Option D, publishing a message to the Pub/Sub topic announcing that a shutdown is in progress, is not a reliable method for initiating a graceful shutdown because the application may not read the message in a timely manner.
A is correct
A seems correct, guys
Looks like D
According to me , it should be D
Because for preemptible instances the script should run within 30 seconds of the instance being shutdown or restarted, in this case a pub sub trigger would be faster to perform.
The issue with option D is that we have a SINGLE PubSub topic that is used to send the rows to be inserted; sending a completely different message seems wrong.
The best answer is A. Write a shutdown script that uses inter-process signals to notify the application process to disconnect from the database. Here's why: Inter-process Signals: Signals are a standard mechanism in Unix-like systems for communicating between processes. They are a reliable and efficient way to notify the application process that a shutdown is imminent. Graceful Shutdown: Using signals allows the application to gracefully disconnect from the database, ensuring data integrity and preventing potential data loss. The application can handle the signal, perform necessary cleanup tasks, and then exit gracefully.
Let's analyze why the other options are less suitable: B. Broadcast message to users: This approach is not a reliable way to initiate a graceful shutdown. It relies on user interaction and might not be effective if users are not actively using the application. C. Write a file for polling: This approach is less efficient and introduces a delay. The application needs to poll the file every five minutes, which can introduce latency and might not be timely enough for a graceful shutdown. D. Publish a message to the Pub/Sub topic: This approach is not ideal because it introduces additional complexity and relies on the application's ability to process messages from the same topic it's subscribing to. It also might not be a reliable way to ensure a timely shutdown.
A. Write a shutdown script that uses inter-process signals to notify the application process to disconnect from the database. In the scenario of using preemptible virtual machines for running an application that interacts with a database, a graceful shutdown is essential to ensure data consistency and prevent potential issues like incomplete transactions. A shutdown script utilizing inter-process signals is an efficient and direct way to manage this process.
I vote A: - https://cloud.google.com/compute/docs/instances/preemptible#preemption - https://cloud.google.com/compute/docs/shutdownscript Option D is not good as we only have a SINGLE pub/sub topic that is also receiving other messages. I wouldn't rely on the new (shutdown) message to come through and be read by the app timely to disconnect from the db.
Option D is a suitable approach for initiating a graceful shutdown in a scenario where the application needs to receive a notification to disconnect from the database before the virtual machine is preempted. Here's how the process works:
Graceful Shutdown: When the application receives the shutdown message from Pub/Sub, it initiates a graceful shutdown, including disconnecting from the database.
Shutdown Script: Write a shutdown script that is executed when the instance is being preempted. Publish a Message to Pub/Sub: In the shutdown script, publish a message to the Pub/Sub topic, indicating that a shutdown is in progress. This message serves as a notification to the application. Application Subscription: The application subscribes to the Pub/Sub topic and continuously listens for incoming messages
You have only one topic, so if there are multiple messages in the queue before the one announcing the disconnect, then a lot of time can pass before the retrival of the message
I will go with A
https://cloud.google.com/compute/docs/instances/preemptible#preemption
it's A Compute Engine sends a preemption notice to the instance in the form of an ACPI G2 Soft Off signal. You can use a shutdown script to handle the preemption notice and complete cleanup actions before the instance stops. https://cloud.google.com/compute/docs/instances/preemptible#preemption
C does not make sense, because you don't know when pub sub message will be consumed (there might other events be in the queue before), so I'll go with option A