English

Google App Engine

Administration Console Questions

How can I delete my app?

You can delete your app, but App Engine provides safety measures to prevent inadvertent deletion. To delete your app, you first disable it, which stops all serving requests but leaves your data and state alone. Once your app is disabled, you can leave it that way, or you can delete it. While your app is disabled, you can still use the Administration Console to manage it. If you delete it, your data and state are destroyed and can't be restored. Even after your application is deleted, its application ID is reserved.

Warning: Disabling your application does not automatically disable billing. If you disable your app but do not disable billing, your app can continue to incur billing costs even though it is disabled.

To delete your app, go to the Administration Console and click Application Settings on the left side under Administration. Then, click Disable Application, and on the next screen, Disable Application Now. This disables your app. While your app is disabled, it won't serve requests. To continue with deleting your app, click Request Permanent Deletion. After a mandatory 72-hour waiting period, your app will be deleted. To stop the pending deletion, go back to the Application Console, click Application Settings, then Manage Disabled Status, and then Revert Deletion Request.

If billing is enabled for your app, you must disable billing before you can delete the app. See the Billing FAQ for general information about billing.

Any of an app's developers can request deletion of the app, but all developers are notified by email and any developer can revert the request for deletion. If an app is deleted, the developer who requested deletion (who is not necessarily the app's creator) receives a "credit" and can then create one additional app. All developer accounts start with the ability to create 10 apps.

How can I get more information about my datastore usage?

The Administration Console includes a page that shows you statistics for entities in your app's Datastore. To see this page, click Statistics on the left side, under Datastore. The Statistics page displays your data in various ways:

  • A pie chart that shows datastore space used by each property type (string, double, blob, etc.).
  • Another pie chart showing datastore space by entity kind.
  • A textual list that gives the total space used by each property type.

By default, the pie charts display statistics for all entities. You can restrict the pie charts to a particular entity kind by choosing from the drop-down menu. The "Metadata" property type represents space consumed by storing properties inside an entry that is not used by the properties directly. The "Datastore Stats" entity, if any, shows the space consumed by the statistics data itself in your datastore.

The statistics data is stored in your app's datastore. To make sure there's room for your app's data, Google App Engine will only store statistics if they consume less than 1 megabyte; otherwise, you won't see any statistics. If your app's stats go over the 1 megabyte limit, any previously reported statistics will remain. There's no way to tell if this has happened to your app, but if you have a lot of data and you're not seeing any statistics, or any updated statistics, this could be the problem. This problem will be addressed in a future version of App Engine.

The space consumed by the statistics data increases in proportion to the number of different entity kinds and property types used by your app. The more different entities and properties used by your app, the more likely you are to reach the 1 megabyte limit.

For information on accessing datastore statistics programatically, see the Python and Java documentation on that subject.

How can my app handle scheduled maintenance outages?

App Engine applications can gracefully degrade during schedule maintenance periods by handling special Capability errors.

For more information, see the Python and Java documentation on graceful degradation during scheduled maintenance.

Migrate from Master/Slave to High Replication Datastore

Currently, the HRD Migration Tool does not support copying data from Blobstore. If you use Blobstore, you need to manually copy that data over.

There might be some app changes recommended for an optimal migration from a master/slave app to an app that uses HRD. For more information, see the following:

You must make a new copy of that app, deploy the new app, and copy data from your old app to the new deployed copy. You do not incur any billing costs when you do this migration.

Here is the overall process:

  1. Create a new copy of your app with a new application ID. You can do this either manually, or you can use the Duplicate Application Settings feature in the Application Settings tab of the Administration Console. Set all properties for the new app to match your settings for the master/slave app, except of course, for the datastore: the new app must use HRD.
  2. Deploy the new copy of your app.

    Note: Deploy your HRD application before copying data to it. If you start copying data before deploying your application, all of the indexes must be rebuilt.

  3. Copy data from your original app's master/slave datastore to HRD using the Migration Tool inside the admin console's Application Settings. This iterative process is described in Using the Migration Tool.

Duplicating Your Application

Note: These instructions use the Duplicate Application Settings feature inside the Application Settings tab of the admin console to copy an app where the copy will use HRD. You could manually accomplish the same thing using other capabilities of the admin console if you wish, but the method described here is the fastest, easiest way to duplicate your app.

To make a copy of your existing app,

  1. Open the admin console, select the app you want to copy, and go to Application Settings.
  2. In the New Application Identifier text box, notice that your current application's application ID is shown with the -hrd suffix. You can use this or provide an entirely new application ID if you wish.
  3. Click Check Availability to verify that the application ID you've chosen is available. Change the ID if necessary.
  4. Click Duplicate Application.
  5. Only the App Title and access control settings are copied over during this copy process. You must manually set the desired app settings, such as Billing, quota settings, and so forth.
  6. When you finish changing your application settings, deploy this app, following the instructions provided for the appcfg tool.

Using the Migration Tool

Note: The use of this tool requires you to first complete the process described in Duplicating Your Application.

The HRD migration tool can migrate your app while your app continues to serve requests and write data to the master/slave datastore. Requests coming in to your app continue to be served by the current app using master/slave during this process, until the copy process is finished and you are ready to switch over to the HRD app. There may be a brief period of time during the switchover when your application may not be able to serve write requests.

Here is the overall process:

  • The first time you run this tool (using Start Migration), the tool copies all existing data in your master/slave datastore to the datastore used by the deployed "HRD version" of your app, and marks any new or changed data after this copy so that further (incremental) copies can be made to copy that new or changed data into the datastore.
  • Run Launch Incremental Copy to capture only the new or updated data marked in the datastore. This run of this tool will be faster than the first.
  • You may need to repeat Launch Incremental Copy) once or twice if your app has a large number of data writes. The idea is to make the time between incremental copies as short as possible before going read-only.
  • When finished with the last incremental copy, click Go read-only. No more data can be written to the master/slave application after you do this.
  • Immediately after the final incremental copy is made, alias the application over to the HRD app (by clicking Complete migration. The new HRD app begins serving incoming requests when you do this.

The migration tool provides a status monitor indicating progress and a time estimate. In addition, you can request an email to be sent to you when the migration tool finishes the current run.

Running the Migration Tool

Note: Deploy your HRD application before copying data to it. If you start copying data before deploying your application, all of the indexes must be rebuilt.

To run a migration,

  1. Open the admin console, select the app you want to migrate, and select Application Settings>View Migration Tool.
  2. In the Destination Application dropdown, select the new HRD application to which you migrating the data.
  3. Click Start Migration, and wait until the data is migrated over to HRD. Click the email checkbox shown in the screen capture above if you wish to be emailed when the job is done. There is no status monitor.
  4. If your master/slave app continues to serve requests during the migration,
    1. Click Launch Incremental Copy and wait for it to finish.
    2. After you run the incremental copy, if your application is writing significant amounts of data, run the incremental copy again. You may need to run Launch Incremental Copy once or twice.
  5. When the data copy phase is complete, click Go Read-Only. This stops the original master/slave app from writing new data to the datastore, although it can serve read-only requests. The Go read-only step performs one final sync while the app is read-only.
  6. Click Complete migration to alias the app over to the HRD app. At this point, the new HRD app begins serving incoming requests.