La reconstrucción siempre falla cuando se agota el límite diario. Creo que sería bueno solucionar esto porque perdí 2 días y configuré un servidor dos veces hasta que descubrí qué causaba este problema. Quizás no soy muy inteligente 
Creo que deberías omitir este proceso y continuar recreando cuando se agote el límite diario.
Sí. Es un gran problema que un error con MAXMIND provoque el fallo de una reconstrucción. Supongo que en su hosting deben compartir la base de datos entre instancias de alguna manera.
No sabía lo del límite diario, pero eso ciertamente explica los errores falsos que he visto. La única solución es deshabilitar maxmind para hacer una reconstrucción.
He mirado el código un par de veces para intentar encontrar una solución, pero aún no lo he hecho. Debe ser una solución de 1 a 3 líneas.
Dado que finalmente has identificado que el problema es su limitación de velocidad, estoy cambiando esto a un 
Desactivo MAXMIND y recompilo, y funciona. Sin embargo, quería informar esto porque pensé que podría sucederle a otros. Gracias por tu interés, buena suerte.
Aquí tienes una solución trivial, pero probablemente eficaz, para este problema:
Dado que no sé exactamente cómo provocar el problema, no es fácil probar el código, pero debería funcionar.
Haré algo de trabajo esta noche y, si veo alguna información sobre el error, actualizaré el tema. Gracias por su tiempo, creo que será útil.
¿Se ha realizado algún estudio sobre este tema? porque acabo de hacerlo y todavía no compila cuando MAXMIND está activado y tuve que cerrarlo para compilar. Podría ayudar, también veo un error de zlip.
NOTA:
Creo que introduje la clave de licencia incorrectamente en app.yml. Lo corregí y volví a compilar. Sin embargo, incluso si es defectuoso o se agota el límite, debe continuar compilando sin dar ningún error.
Para ese error, ¿tienes también DISCOURSE_MAXMIND_ACCOUNT_ID añadido a tu app.yml?
¿Puedes compartir todos los registros?
Si vuelvo a encontrar este error, compartiré los registros de errores, pero es el mismo que en el enlace que me diste.
Por otro lado, cuando la clave es incorrecta, la compilación da un error. Por lo tanto, sería una buena idea que esta función continuara y diera una advertencia si hay una clave o ID incorrectos.
Well, it seems not to work with what I’m fairly certain is a valid maxmind key. I guess since I have several sites on the same IP all requesting the database I’m hitting rate limits?
...
Checking 'Guest Gate Theme Component' for 'default'... up to date
Checking '* Official: discourse-search-banner' for 'default'... up to date
Checking '* Official: Header submenus' for 'default'... up to date
Checking '* Auto linkify words (official)' for 'default'... up to date
Checking '* Official: New PM Dropdown Button (KED)' for 'default'... up to date
Checking 'Sidebar Theme Toggle' for 'default'... up to date
Downloading MaxMindDB...
FAILED
--------------------
Plugin name is 'DiscourseAddToSummary', but plugin directory is named 'discourse-add-to-summary'
Purging temp files
Bundling assets
I, [2024-07-03T15:34:03.558862 #1728] INFO -- : Writing /var/www/discourse/public/assets/break_string-cc617154cd957804f2f6a1f3bc68258c9cdca3d4b9a322
bf777d145fed04790e.js
I, [2024-07-03T15:34:03.565737 #1728] INFO -- : Writing /var/www/discourse/public/assets/service-worker-1c2f90c0e9ecfcf748d58ed6c37a510b3cd246299fcf
a5917a060293f1affb92.js
I, [2024-07-03T15:34:03.568027 #1728] INFO -- : Writing /var/www/discourse/public/assets/locales/i18n-3b40e842fd72b9bcc74ea83e094c823cd9ca535e4ecc5e
78722e6f99d3656137.js
I, [2024-07-03T15:34:03.569522 #1728] INFO -- : Writing /var/www/discourse/public/assets/scripts/discourse-test-listen-boot-9b14a0fc65c689577e6a428d
cfd680205516fe211700a71c7adb5cbcf4df2cc5.js
I, [2024-07-03T15:34:04.079476 #1728] INFO -- : Writing /var/www/discourse/public/assets/locales/ar-583c921ae692b1e7c988997efcba99e6b41b62572682166e
2c62bae0caeaab2b.js
I, [2024-07-03T15:34:04.373049 #1728] INFO -- : Writing /var/www/discourse/public/assets/locales/be-ee1a0dd42713e1ca29dbacea5dcde76c51a441cb634c5d61
7ba4b20bb7ef5b05.js
rake aborted!
Zlib::BufError: buffer error (Zlib::BufError)
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sprockets-3.7.3/lib/sprockets/cache/file_store.rb:100:in `<<'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sprockets-3.7.3/lib/sprockets/cache/file_store.rb:100:in `set'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sprockets-3.7.3/lib/sprockets/cache.rb:212:in `set'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sprockets-3.7.3/lib/sprockets/cache.rb:136:in `set'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sprockets-3.7.3/lib/sprockets/loader.rb:243:in `store_asset'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sprockets-3.7.3/lib/sprockets/loader.rb:185:in `load_from_unloaded'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sprockets-3.7.3/lib/sprockets/loader.rb:60:in `block in load'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sprockets-3.7.3/lib/sprockets/loader.rb:317:in `fetch_asset_from_dependency_cache'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sprockets-3.7.3/lib/sprockets/loader.rb:44:in `load'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sprockets-3.7.3/lib/sprockets/cached_environment.rb:20:in `block in initialize'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sprockets-3.7.3/lib/sprockets/cached_environment.rb:47:in `load'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sprockets-3.7.3/lib/sprockets/base.rb:66:in `find_asset'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sprockets-3.7.3/lib/sprockets/base.rb:73:in `find_all_linked_assets'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sprockets-3.7.3/lib/sprockets/manifest.rb:134:in `block in find'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sprockets-3.7.3/lib/sprockets/manifest.rb:133:in `each'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sprockets-3.7.3/lib/sprockets/manifest.rb:133:in `find'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sprockets-3.7.3/lib/sprockets/manifest.rb:186:in `compile'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sprockets-rails-3.5.1/lib/sprockets/rails/task.rb:67:in `block (3 levels) in define'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sprockets-3.7.3/lib/rake/sprocketstask.rb:147:in `with_logger'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sprockets-rails-3.5.1/lib/sprockets/rails/task.rb:66:in `block (2 levels) in define'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rake-13.2.1/exe/rake:27:in `<top (required)>'
/usr/local/bin/bundle:25:in `load'
/usr/local/bin/bundle:25:in `<main>'
Tasks: TOP => assets:precompile
(See full trace by running task with --trace)
I, [2024-07-03T15:34:04.978774 #1] INFO -- : Checking 'Add(back) Category Colmn (TH)' for 'default'... up to date
Checking '* Official: discourse-placeholder-theme-component (JP)' for 'default'... up to date
Checking '* Discourse Easy Footer (Official)' for 'default'... up to date
Checking 'discourse-user-field-prompt' for 'default'... up to date
Checking '* Rotate Global Banner(JP)' for 'default'... up to date
Checking 'Guest Gate Theme Component' for 'default'... up to date
Checking '* Official: discourse-search-banner' for 'default'... up to date
Checking '* Official: Header submenus' for 'default'... up to date
Checking '* Auto linkify words (official)' for 'default'... up to date
Checking '* Official: New PM Dropdown Button (KED)' for 'default'... up to date
Checking 'Sidebar Theme Toggle' for 'default'... up to date
Downloading MaxMindDB...
FAILED
--------------------
Pups::ExecError: cd /var/www/discourse && su discourse -c 'SKIP_EMBER_CLI_COMPILE=1 bundle exec rake themes:update assets:precompile' failed with ret
urn #<Process::Status: pid 1726 exit 1>
Location of failure: /usr/local/lib/ruby/gems/3.3.0/gems/pups-1.2.1/lib/pups/exec_command.rb:132:in `spawn'
exec failed with the params {"cd"=>"$home", "tag"=>"precompile", "hook"=>"assets_precompile", "cmd"=>["su discourse -c 'SKIP_EMBER_CLI_COMPILE=1 bund
le exec rake themes:update assets:precompile'"]}
bootstrap failed with exit code 1
** FAILED TO BOOTSTRAP ** please scroll up and look for earlier error messages, there may be more than one.
./discourse-doctor may help diagnose the problem.
Subsequent rebuild with the Maxmind key and id commented out succeeds.
Why is this so hard?
So here’s the limit from
I’m not quite clear how I’d be hitting these limits, but it’s the only explanation other than spurious downtime on their servers?
Para mí, ese límite se activa cada vez que reconstruyo un servidor más de una vez al día.
También recibo un correo electrónico que comienza así (énfasis mío)
Así que, aparentemente, también hay un límite por IP.
Eso es de gran ayuda. Nunca había visto ese correo electrónico.
Podría ser capaz de hacer algo para evitar que los servidores múltiples en una sola IP hagan eso, pero no poder reconstruir dos veces en un día parece un desafío. Supongo que un proxy de caché es lo único que se me ocurre.
Estaría feliz de pagarles una cierta cantidad de dinero para que esto no sea un problema, pero no veo una manera de hacerlo.
Pero es algo más que límites de tasa porque después de construir la imagen, fui y establecí los valores en /var/www/discourse/config/discourse.conf y ejecuté la tarea de rake y descargó la base de datos sin problemas.
¿Podría la base de datos vivir en almacenamiento persistente?
¿Podría descargarse la base de datos solo después de que se inicie la imagen?
@JammyDodger ¿has podido compilar con Maxmind desde el último lanzamiento? @RGJ – ¿has tenido algún problema?
No creo que ningún sitio que haya probado con maxmind haya funcionado. Y el que hice ayer pudo descargar la base de datos con la tarea rake después de que entré y edité la configuración dentro del contenedor con la misma configuración que causó que el arranque fallara.
Ha habido varios otros temas sobre fallos debido a Maxmind.
El otro día tuve un fallo en la reconstrucción incluso con el ID de cuenta de Maxmind, pero otra justo después se completó sin problemas.
No hemos tenido ningún problema, (pero estamos usando nuestro propio sistema de implementación).
Lo acabo de probar y puedo recuperar el archivo 10 veces desde la misma IP (y luego dejé de intentarlo).
Así que mi “solución” para evitar que un error matara la reconstrucción falló.
Así que esto será muy difícil de depurar.
Tuve el mismo correo electrónico (y problema) después de mover algunos foros a un nuevo servidor, así que estoy de acuerdo con el OP, quizás mostrar una opción para reconstruir, o, intentar obtener la base de datos antes de que comience la reconstrucción dándonos la opción de ‘intentar de nuevo’ o ‘reconstruir sin maxmind’.
fwiw, el cambio reciente a que requieren clave de API + nombre de usuario en lugar de solo clave de API también provocó que nuestra actualización/reconstrucción fallara, causando varios días de inactividad.
De acuerdo con otros, deshabilitar/comentar en app.yml >> reconstruir = lo solucionó. Aún no lo hemos vuelto a habilitar ya que estamos esperando cualquier solución que pueda ser esta.
¿Tienes el mensaje de error de dónde falló la reconstrucción?